NASA/TM-2001 -21 1 027 



Description of Selected Algorithms and 
Implementation Details of a Concept- 
Demonstration Aircraft VOrtex Spacing 
System (A VOSS) 


David A. Hinton 

Langley Research Center, Hampton, Virginia 


June 2001 




The NASA STI Program Office ... in Profile 


Since its founding, NASA has been dedicated 
to the advancement of aeronautics and space 
science. The NASA Scientific and Technical 
Information (STI) Program Office plays a key 
part in helping NASA maintain this important 
role. 

The NASA STI Program Office is operated by 
Langley Research Center, the lead center for 
NASA's scientific and technical information. 
The NASA STI Program Office provides 
access to the NASA STI Database, the largest 
collection of aeronautical and space science 
STI in the world. The Program Office is also 
NASA's institutional mechanism for 
disseminating the results of its research and 
development activities. These results are 
published by NASA in the NASA STI Report 
Series, which includes the following report 
types: 

• TECHNICAL PUBLICATION. Reports 
of completed research or a major 
significant phase of research that 
present the results of NASA programs 
and include extensive data or theoretical 
analysis. Includes compilations of 
significant scientific and technical data 
and information deemed to be of 
continuing reference value. NASA 
counterpart of peer-reviewed formal 
professional papers, but having less 
stringent limitations on manuscript 
length and extent of graphic 
presentations. 

• TECHNICAL MEMORANDUM. 
Scientific and technical findings that are 
preliminary or of specialized interest, 
e.g., quick release reports, working 
papers, and bibliographies that contain 
minimal annotation. Does not contain 
extensive analysis. 

• CONTRACTOR REPORT. Scientific and 
technical findings by NASA-sponsored 
contractors and grantees. 


• CONFERENCE PUBLICATION. 
Collected papers from scientific and 
technical conferences, symposia, 
seminars, or other meetings sponsored 
or co-sponsored by NASA. 

• SPECIAL PUBLICATION. Scientific, 
technical, or historical information from 
NASA programs, projects, and missions, 
often concerned with subjects having 
substantial public interest. 

• TECHNICAL TRANSLATION. English- 
language translations of foreign 
scientific and technical material 
pertinent to NASA's mission. 

Specialized services that complement the 
STI Program Office's diverse offerings 
include creating custom thesauri, building 
customized databases, organizing and 
publishing research results ... even 
providing videos. 

For more information about the NASA STI 
Program Office, see the following: 

• Access the NASA STI Program Home 
Page at http://www.sti.nasa.gov 

• E-mail your question via the Internet to 
help@sti.nasa.gov 

• Fax your question to the NASA STI 
Help Desk at (301) 621-0134 

• Phone the NASA STI Help Desk at (301 ) 
621-0390 

• Write to: 

NASA STI Help Desk 

NASA Center for AeroSpace Information 

7121 Standard Drive 

Hanover, MD 21076-1320 



NASA/TM-2001 -21 1 027 



Description of Selected Algorithms and 
Implementation Details of a Concept- 
Demonstration Aircraft VOrtex Spacing 
System (A VOSS) 


David A. Hinton 

Langley Research Center, Hampton, Virginia 


June 2001 



Available from: 


NASA Center for AeroSpace Information (CASI) 
7121 Standard Drive 
Hanover, MD 21076-1320 
(301) 621-0390 


National Technical Information Service (NTIS) 
5285 Port Royal Road 
Springfield. VA 22161-2171 
(703) 605-6000 



Description of Selected Algorithms and Implementation Details of a 
Concept-Demonstration Aircraft VOrtex Spacing System (AVOSS) 


A ground-based wake vortex system was developed to demonstrate the feasibility of providing weather- 
dependent wake vortex spacing criteria for Ah Traffic Control use. The system provides automated 
collection of relevant weather data, prediction of wake vortex behavior, derivation of safe wake vortex 
spacing criteria, estimation of system benefit, and comparison of predicted and observed wake vortex 
behavior. This report describes many of the system algorithms, features, limitations, and lessons learned, 
as well as suggestions for system improvements. A condensed version of the development lab book is 
provided along with samples of key input and output file types. This report is intended to document the 
technical development process and system architecture, and to augment archived internal documents that 
provide detailed descriptions of software and file formats. 

Scope and Development Approach 

The AVOSS hardware and software were designed and developed to provide a concept feasibility 
demonstration of a spacing system concept. The demonstration AVOSS was developed to fulfill several 
concept demonstration and research requirements: 

1 . Automate assimilation of relevant weather and aircraft information for wake prediction. 

2. Convert wake predictions to spacing values and estimated runway throughput. 

3. Operate fully automated, without human intervention to screen data or provide real-time decisions. 

4. Automate collection of performance statistics and error (diagnostic) statistics. 

5. Provide adequate flexibility for iterative system implementation as lessons were learned in field 
operations and as subsystems matured. 

6. Provide flexibility in field operations, for example to relocate a wake sensor. 

7. Operate with specific field sensors deployed, and operate in batch mode for sensitivity studies. 

The demonstration system was not required to provide an information interface to Air Traffic Control nor 
possess the reliability or safety feedback mechanisms required for actual spacing reduction. The system 
design process was complicated by the lack of specific requirements. Since no wake spacing system has 
been produced or used operationally in the U.S., specifications such as altitude and weather domains to be 
considered, sensor resolution and accuracy, system update rates, and ATC information requirements were 
not available. Even with respect to known functional requirements, such as wake vortex drift and decay 
prediction, the state of the art did not allow specification of a weather system (parameters, resolution, 
accuracy required) to produce the needed inputs. The development approach taken was one of iterative 
builds, learning, and refinement. 

Available knowledge at the project outset was used to field an initial system for the puiposes of testing 
sensors, collecting a complete aircraft/wake vortex/weather data set for numerical model validation, and 
answering subsystem performance issues needed to perform more detailed system design. The resulting 
deployments' to the Memphis International Airport in 1994 and 1995, were optimized for scientific data 
collection and testing of advanced Continuous Wave (CW) lidars for wake detection and tracking. The 
meteorological instrumentation was assembled in cooperation with NO A A, MIT Lincoln Laboratory, 

Volpe National Transportation Systems Center, FAA, and others. The resulting instrumentation was the 
most comprehensive used to date for wake vortex studies. No AVOSS system was present at those 
deployments and data was reduced and analyzed after the fact. Data from the Memphis deployments were 
used in the validation of numerical wake vortex simulation models 4 , for evaluating existing and new 
algorithmic wake vortex prediction models 5 ’ 6 , refining and validating planetary boundary layer simulation 
models 7 , and refinement and selection of sensors for use in AVOSS. 

The Memphis field systems were moved to the Dallas-Fort Worth International Airport (DFW) in 1997 for 
integration into the initial AVOSS. Dallas was chosen due to significant daytime traffic, presence of the 
Center-TRACON Automation System (CTAS) and an Integrated Terminal Weather System (ITWS). and 
adequate real estate for flexible sensor siting. Components added for the DFW tests (not present at 




Memphis) were a pulsed wake vortex lidar s developed at NASA Langley Research Center, two identical 
acoustic sodars to replace a borrowed sodar at Memphis, and the networks required for real-time linkage of 
all systems to a central location to support AVOSS operation. The DFW AVOSS systems performed two 
separate functions: (1) gathering additional scientific data for validation of numeric wake vortex and 
planetary boundary layer models and for wake algorithm development, and (2) operation and refinement of 
an automated wake vortex spacing system. The two functions frequently required different data 
characteristics. For example scientific use of data for wake model development required that the wind 
values during a wake lifetime, typically 1 to 2 minutes, be quantified near the wake location, while AVOSS 
requires a statistical description of a mean wind and confidence intervals over a period of about 30 minutes. 
Scientific model validation also required dedicated rawinsonde balloon launches during deployments, while 
AVOSS did not use that data set at all. As a result the field sensors represent a superset of those sensors 
required by an operational system, but the presence of those sensors provided additional redundancy for 
AVOSS operations, and the archived data sets are available to investigate alternative processing methods. 

The DFW installation was used from late 1997 through 2000 to incrementally test the AVOSS concept, 
refine the concept and subsystems, and perform a system capability demonstration in July 2000. It was 
judged to be more efficient to begin operations with existing maturity levels of each component, and then 
learn which functions were most critical to system operation and performance prior to focusing on specific 
subsystem refinements. The demonstrated system contains an initial implementation of most functions 
required for an operational system, but without the robustness needed for an operational system. 

General Design Architecture 


Software Functions: 

Numerous interrelated functions were implemented within AVOSS, many of which are not required in 
wake vortex sensor installations deployed solely for research purposes. These functions include: 

1. Definition of approach corridor lateral and vertical limits in an absolute runway coordinate system. 

2. Definition of specific locations along the corridor, called windows, to include the window location 
in space, glide slope height, and vertical/lateral corridor limits at that window. Wake vortex 
behavior predictions and observations are only made at these discrete window locations. 

3. Ability to add window locations at run time, to accommodate new wake sensor locations or other 
factors. 

4. Maintain a database of aircraft representing the arrival flow, with all information needed to 
estimate both initial wake state and final approach speed. The database represents an assortment 
of large and heavy aircraft types, including estimated “worst-case” types within a category. 

5. Accept weather profiles (weather parameters vs. height) and associate weather parameters with 
each approach corridor window based on the glide slope altitude. An assumption is made 
regarding spatial homogeneity of weather statistics, i.e. mean wind over a 30-minute period, in 
that the wind statistics at a specified distance from the runway may be found by finding the glide 
slope height at that distance and selecting the weather statistics from a single profile at that 
altitude. 

6. Predict wake vortex behavior at each corridor window for each aircraft. 

7. Estimation of wake prediction confidence intervals to determine worst-case behavior. 

8. Compare wake behavior to corridor dimensions and a wake demise definition to derive the 
minimum tune spacing required behind each aircraft at each window. 

9. Provide automated quality assessment of derived weather profiles and disable, or lock out, the use 
of wake drift when confidence is low in the crosswind parameter. Wake lateral drift is not used 
for spacing reductions when the crosswind standard deviation exceeds a threshold. 

10. Compute the spacing requirement at each window (window spacing). Using estimated aircraft 
speeds and wind, calculate spacing required at the top of the approach (approach spacing) required 
to meet all constraints along the approach. Convert aircraft type-based data (i.e., wakes behind a 
B-737) to aircraft category-based data (i.e., separation behind large aircraft). 
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11. Limit spacing values to fall between a minimum value, dictated by runway occupancy time, and 
an upper value dictated by current spacing criteria. The lower limit is needed to avoid providing 
absurd spacing criteria such as Vi mile when wakes are rapidly drifting or decaying, and the upper 
limit need will be described below. 

12. Calculate estimated runway arrival rate using these separation values and airport traffic mix, or 
ratio of small, large, and heavy aircraft. Estimate the base arrival rate using current static spacing 
criteria to estimate the increase due to AVOSS. 

13. Detect and track wake vortices in a runway coordinate system (not local axis system at the sensor) 
and in absolute time from aircraft passage. This requires data to augment base sensor data since 
the wake lidars cannot be expected to detect aircraft passages from skin-hits of the lidar beam. 

14. Compare predicted and observed wake behavior to detect system prediction errors and accumulate 
performance statistics. This function would be enhanced to a warning, or safety monitoring, 
function in an operational system. 

15. Provide logging of results and displays for real-time and post-event interpretation of results. 

The demonstration AVOSS was intended as a proof-of-concept system and a tool for performance and 
tradeoff studies, not as an operational system. Also, since system design requirements did not exist at the 
beginning of the project, an iterative design and build process was followed to determine essential system 
functions and refine those most critical to performance. As such, the functions listed above are only 
developed to the degree required for research and demonstration puiposes. Suggestions for future system 
improvement ate provided in Appendix A. 


Software Architecture: 

The system was designed as a core set of functions and software, applicable to the general AVOSS concept, 
and a shell, or interface, required to run the core with the specific sensors installed at the DFW airport. 
Figure 1 depicts the general architecture. Information is passed from one process to another via files on 
networks or shared disk space. The core modules accept three basic weather information files, an aircraft 
specification data base, and a parameter file describing run configuration, and then computes wake 
behavior predictions, derives spacing criteria and throughput, and writes diagnostic log files. Examples of 
the aircraft database, parameter file, and output spacing files are given in appendices B and C. The three 
weather files provide vertical profiles of wind, turbulence, and temperature. This core code is suitable for 
field use, for batch runs with archived input data, or with input data created to investigate behavior in 
specific situations. The fust method of batch running is useful for investigating long-term system 
performance with archived data for variations in system algorithms or parameters ’, while the latter is useful 
for sensitivity studies 10 to investigate the relative contributions of the various inputs. 

The shell modules perform functions more specific to the DFW installation, such as derivation of the three 
weather file types from the specific sensor compliment used and comparison of predicted wake behavior to 
that observed by the wake sensors. Figure 2 shows a detailed breakdown of the weather data flow. The 
wind profile is created by a process managed by MIT Lincoln Laboratory that combines data from two 
acoustic sodars, a radar profiler, wind sensors along a 45-meter tall tower, and two nearby Terminal 
Doppler Weather Radar (TDWR) systems 11 . The turbulence profile is generated using eddy dissipation rate 
calculated from 10-Hertz sonic anemometer data at the meteorological tower, other tower data, and 
atmospheric similarity theory 12 . The thermal profile is calculated from tower temperature measurements 
and temperature aloft data from the Radio Acoustic Sounding System associated with the radar profiler. 
Each process includes quality checks of the input data and quality indicators in the output files. An 
example of the flexibility of this approach (separation of software into a core and shell) was operation of 
the AVOSS driven only by pulsed-lidar data at the JFK International Airport ’ in 1998. In this test the 
AVOSS core code was unchanged, but the pulsed lidar was used to derive a wind and turbulence profile 
normally provided by the shell code and DFW sensors. These input files were provided to AVOSS, along 
with a static neutrally-stable thermal profile, to drive wake predictions. 
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Description of Selected Algorithms 


This section will provide a description of several internal algorithms within the AVOSS. Not described is 
the wake predictor algorithm. Wake predictor algorithms are described in references 5, 6, 13 and 14. The 
algorithms to be discussed here are dimensions of the AVOSS corridor, calculation of approach spacing 
from individual window spacing, definition of weather quality requirements for use in spacing reduction, a 
lockout feature that prevents use of lateral drift in low wind, throughput calculation, and scoring of wake 
predictions with wake observations. 


AVOSS Corridor Dimensions 

The coordinate system used to describe the approach corridor, wind values, and wake locations is shown in 
Figure 3. The origin is fixed at the center of the runway threshold, the X-axis extends along the localizer 
and is positive toward the outer marker, the Y -axis extends laterally to the right, as viewed by an 
approaching aircraft, and Z is positive upwards. When runway-axis wind values are provided, a positive 
longitudinal wind is a headwind (positive X-derivative of the position of an air particle) and a positive 
crosswind is one that blows from left to right of an approaching aircraft (positive Y-derivative). 

The AVOSS corridor has three major components, the region close to the ground where the wakes are 
interacting with the surface, the area above this zone and where aircraft are on glide-slope, and the top-of- 
approach. The largest zone is between the glide-slope intercept and the region of ground effect on the 
wake. In this zone wakes can vacate the corridor either via lateral drift, vertical sinking below the glide- 
slope, or decay. A corridor floor is established, below which wakes are not considered a factor to following 
aircraft. The floor is defined such that a following aircraft at the floor would either be below glide-slope, to 
the extent that a glide-slope deviation indicator in the cockpit would show “full-scale” error, or at higher 
altitudes the altitude deviation from assigned altitude would be on the order of 60 meters (at least 200 feet). 
The lateral limits are set in this region to protect an aircraft flying a 3-standard deviation localizer error, as 
determined from previous flight technical error data collected at two major airports' \ 

As an aircraft approaches the ground, the wakes become affected by the earth’s surface. Wake sink rate 
slows and stops near the ground, generally asymptoting to an altitude between about one-half and three- 
quarters the wingspan of the wake-gene rating aircraft 6 . Wakes generated at lower altitudes tend to rise 
to an altitude of one -half span. Since the ground interferes with wake sinking, it is not feasible to vertically 
separate aircraft from wakes near the ground. In this region the AVOSS corridor floor is defined to be at 
ground level, which effectively removes wake vertical position from the spacing calculations. The altitude 
of the transition from no vertical motion allowance to a useable corridor floor is at an aircraft altitude of 
about 61 meters (200 feet). The rationale is that the largest span aircraft today (65 meters or 215 feet) will 
generate wakes that will tend to seek a minimum altitude of 100 feet, and the corridor option chosen 
provides an altitude buffer of 100 feet above such a wake. 

The top of the approach is unique from one perspective. While on glide slope the aircraft are flying with 
precise lateral and vertical guidance. Prior to intercepting the glide slope, however, the aircraft are 
generally flying an assigned altitude, but with less precise lateral guidance prior to intercepting the 
localizer. At the top of the approach, defined to be the glide-slope intercept altitude, the corridor is 
artificially widened to a large value to prevent spacing reduction due to lateral drift. At this altitude the 
aircraft spacing is calculated from wake sink and decay only, implying that the spacing provided is safe to 
use while intercepting the localizer. The mechanism of implementing this feature proved awkward for later 
sensitivity studies, and future implementations should instead consider a logic lockout of drift at specific 
altitudes rather than an arbitrary corridor width change. 

The following equations provide the dimensions of any particular corridor window, in terms of Y| im (lateral 
distance of the corridor side from the localizer, meters), Z ]HH (altitude of the corridor floor, meters). The 
window information is calculated as a function of the window distance from the runway threshold (X). 
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Base equations: 


The altitude of the nominal flight path is assumed to be the glide slope of the instrument landing system. 
Given that GS A is the glide slope angle (typically 3 degrees), and that the subscripts FP and GPIP refer to 
“flight path” and “glide path intercept point” on the runway surface (typically negative 305 meters), the 
altitude (Z) of the flight path can be calculated from the X coordinate by: 

Z FP = (x- X GPIP ) tan(GSA) (1) 


A transition point on the approach is used defined the location where the corridor floor transitions from a 
specified height below the glide slope to ground level. Between this point and the runway the corridor 
floor is at ground level, preventing wake sinking motion from being used to reduce spacing. 


X T = Integer(X GP[P 


60.9756 

tan(GSA) 


( 2 ) 


In this equation the constant 60.9756 is the flight path height in meters at the location of the transition 
point. 

Corridor lateral limit equations: 

The corridor lateral limit is represented by Y Um , which is the absolute value of the Y coordinate of corridor 
walls. A Yum of 50 meters indicates that the corridor is 100 meters wide centered on the X axis. Corridor 
limits are calculated for three discrete regions from the runway. 

If x<X T =45.73 

If X T <x<X sp =45.73 + 0.012695(x-X r ) (3) 

If x>X SP F lim =10000 


In these equations X SP is the coordinate of the “spacing point” used for calculation of the top-of-approach 
spacing. In the current system this point was at the assumed glide slope intercept point of 600 meters 
altitude and 1 1 128 meters from runway tlueshold. The step change in corridor width at the spacing point 
was used to disable lateral wake drift as a spacing reduction factor beyond the glide slope intercept. In the 
absence of this step the corridor would be about 352 meters wide at that point (176 meters each side of 
centerline). 

Corridor floor equations: 

Previous reports 18 described two corridor floor options. Only option 2 was used in the final years of the 
AVOSS project. The floor equations are: 

If x<X T = 0 

If X T <x<X SP Z^=Z fp -(213 + 0.00411 (x-X t )) (4) 

If x > X SP Z lim = Z FP - (21.3 + 0.0047 1(X SP - X T )) 


These equations state that the corridor floor is at ground level (Z = 0) from the railway to the transition 
point, then steps to an altitude of 21.2 meters below flight path, increases in distance below flight path out 
to the glide slope intercept, then remains at a constant altitude. At and beyond the glide slope intercept in 
the current implementation the corridor floor is 69.7 meters (229 feet) below the flight path. 
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Objects within the AVOSS core code (implemented in C++) represented approach corridor windows. A 
default set of 6 windows is created when the program initializes the approach. These windows are located 
at X = 0, 430, 843, 982, 5000, and 1 1 128 meters. The window at 843 meters is at the location where the 
corridor floor steps from ground level to a calculated distance below glide slope, and the window at 982 
meters was co-located with the windline wake sensor deployed by Volpe. The last window, at 1 1 km from 
the runway, is at the top of approach for a typical approach scenario, not for the published approach to 
runway 17C. AVOSS has the ability to dynamically create other windows as required to accommodate the 
changing location of wake sensors. Typical locations of the additional windows at the system 
demonstration were X = 84 meters (Continuous Wave (CW) Lidar location), and X = 1080, 1702, and 2262 
meters (pulsed Lidar scan locations). 

Approach Spacing Calculation 

Several steps are followed to compute the approach spacing from the wake predictions. Figure 4 shows the 
flow of information in the AVOSS software when estimating wake behavior and spacing. The steps are: 

1. The shell code invokes AVOSS with a weather data set and aircraft and parameter file data. The 
three weather files describe vertical profiles of 30-minute statistics of runway axis winds (cross 
wind and head wind), turbulence, and temperature. The wind values include both the mean and 
standard deviation of the 30-minute wind values. 

2. Use weather and aircraft data to compute the wake trajectories of each aircraft at each approach 
window. Run the wake predictor with three crosswind values (mean, mean - standard deviation, 
mean + standard deviation) to predict a range of wake drift behaviors. In certain situations where 
the drift factor cannot regulate the spacing, only the mean wind run is made. 

3. Compare the time history of each wake track to the window dimensions to derive a vertical and 
horizontal residence time of the port and starboard wake, for each aircraft at each window. Of the 
three wake predictor runs made in step (2), only the largest drift time is used. A demise time value 
is also determined by comparing the predicted wake strength history to a wake demise value. If a 
particular time value cannot be determined, that value is filled with the value of 9999. 

4. Apply lockout conditions to the time values. For example, if the crosswind is low relative to the 
standard deviation, as described below, the lateral residence times of both wakes are set to the 
value 9999. Similarly, low confidence in the weather data quality can reset times to 9999 in the 
residence time computation. 

5. Combine the wake vortex lateral, vertical, and demise times into a wake pair residence time value, 
using the equation: 

^ pah- ~ MaxlMin{x pl ,t pv ■,? pD)iMin(T sv ,T spY) (5) 

where the values are tune (seconds) and the subscripts P, S, L,V, and D refer to port, starboard, 
lateral, vertical, and demise, respectively. In words, the equation says that the port wake is no 
longer a factor when any of its factors (lateral, vertical, or demise) removes it from the corridor, 
and that the wake pair is no longer a constraint when both the port and starboard wake are no 
longer in the corridor. 

6. Use wind and aircraft speed data to predict the time required at the top of the approach that is 
required to meet the constraint at the window. Wind data (head wind component) is taken from 
the weather profiles and a typical aircraft speed is taken from an aircraft data base file. The point 
at the top of the approach at which the spacing is calculated is referred to as the "spacing point”. 
The top-of-approach requirement is useful from several standpoints; (a) it integrates the wake 
constraints at each window and provides a single value that would be useful to air traffic control, 
(b) it allows a system-level assessment of benefits, since reduced spacing at one location does not 
affect overall spacing unless that location was constraining the approach, and (c) provides an input 
to a simple approach throughput calculation. Note that the speed of both the generator and 
follower aircraft are required for this process. Since the type of aircraft to follow a particular 
aircraft is not known in advance, and since small aircraft are not included in the aircraft data base 
file, a conservative approach is to assume the maximum speed of each follower category in this 
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calculation. The maximum approach speed assumed for each follower category is included as a 
parameter in the aircraft data base file. 

7. The top-of-approach spacing values provided in step 6 are time values and are calculated for each 
aircraft in the data base file and for each approach window. The time values from each window 
are used to determine a worst-case tune for approach spacing and then the approach spacing 
criteria are converted to distance values. For each generator aircraft the spacing point time 
requirement behind it is calculated by: 


t SP = MAX 


T + - 

pair ,n 


(x SP -x„) 


(X sp -X„) 


w=0 L 


V a ~\(HW sr +HW h ) 


\jHW sr +HW„) 


( 6 ) 


where n represents the individual approach windows, T pailn is the wake pair residence time at 
window n, X is the runway x-axis coordinate distance (distance from runway threshold), HW is 
the headwind at the location given, V g is the estimated airspeed of the generator aircraft, V fmax is 
the maximum estimated airspeed of the aircraft in the follower category of interest, and subscripts 
SP and n refer to the location of the spacing point and of the window generating the value of T pa j lin . 
The headwind at a given location is determined from the glide slope altitude at that location and 
the wind data at that altitude in the wind profile. The headwind at the spacing point and the 
window are averaged as an approximation to the average headwind between those two locations, 
and then used to convert airspeed to ground speed. Effectively, this equation is adjusting the wake 
time requirement at window n by the difference in the time required by the lead and the follower 
aircraft to fly from the spacing point to the window, than taking the largest of the adjusted window 
time from all windows as the top-of-approach requirement for that aircraft pair. For each 
generator weight category (large and heavy) AVOSS determines the worst-case time behind the 
individual generator aircraft. For example if 5 “large” aircraft are in the aircraft data base, the 
largest of 5 aircraft approach spacing values will be found to determine the following time behind 
large aircraft. Figure 5 shows how individual window and aircraft type residence times are used to 
generate a category-based top-of-approach spacing. In this example there are 3 windows (at X = 

0, 900, and 11000 meters), 2 large aircraft types (LI and L2) and 2 heavy aircraft types (HI and 
H2) in the wake predictor database, where LI is a particular type such as a Boeing 737. Assumed 
approach speeds are 60 m/s for LI, 70 m/s for L2, 70 m/s for HI, and 80 m/s for H2. No small 
aircraft are in the database, but the assumed maximum approach speed for all small, large, and 
heavy aircraft is 60, 70, and 80 m/s respectively. Headwind is zero at all altitudes in this example. 
The column “wake residence tune” provides residence time data for each aircraft-window 
combination derived from wake predictions and corridor definitions. The “delta time” column is 
provided by the 2nd and 3rd terms inside the brackets of equation 6 and is computed for each 
weight category that can trail a given aircraft type. The “time adjusted” column represents all 
terms in the brackets of equation 6. For example a heavy aircraft hailing a type LI must be 90.8 
seconds in hail at the spacing point in order to meet a 45 -second requirement at window 1. The 
“maximum” column represents the output of equation 6, the spacing point time that meets all 
window requirements. Finally the category-based output reduces the 3xn matrix (3 trail categories 
and n generator types) to a 3x2 matrix in this example. In the actual system the B-757 is heated as 
a 4th generator category and small generator data is provided using FAA provided criteria. Note 
that aircraft types must not be combined until after determining the top-of-approach criteria. For 
example if the window 1 residence time values for both large aircraft were combined initially, the 
worst case value of 65 seconds would be used to provide the worst-case time adjustment of 26.2 
seconds for a top-of-approach value of 9 1.2 seconds for large aircraft following large aircraft, 
while only 71.2 seconds is actually required. Note also that the final approach spacing value given 
is not dependent on just one window. In some cases window 1 set the approach spacing values, in 
other cases window 3 drove spacing. 


7 



8. Convert time values to distance values. This final step is performed primarily for output display 
puiposes. Time is used internally to represent spacing. While all internal calculations are 
performed in metric units, spacing distance is converted to nautical miles for display. 

Note above that the tune value of 9999 is used to denote residence time factors that cannot be quantified. 
This value is used both in wake predictions and in wake observations. For example the wake predictor 
algorithm terminates at a preset elapsed time, typically 120 to 180 seconds. If termination takes place prior 
to the wake drifting laterally from the corridor, then it is not possible to define a lateral residence time and 
that value is set to 9999. If a wake sensor does not observe a wake to sink below the corridor floor then no 
vertical residence time can be defined and the value is reported as 9999. Data uncertainties must be 
accommodated in the design, and the fact that a wake is not observed to exit the corridor is a different 
statement than saying the wake was observed to remain in the corridor. Frequently wake sensors will lose a 
wake track prior to a wake exiting the corridor, for example due to wake demise. In many cases the wind 
line did not detect wakes until they had already drifted outside the corridor, since wakes had to sink close to 
the wind line for detection. Since the transition from inside the corridor to outside the corridor was not 
observed in these cases, lateral residence time was reported as 9999. The ability to disable any predicted 
wake factor from reducing spacing was implemented in software by resetting predicted residence times for 
that factor to 9999. For example to ignore lateral drift when calculating spacing, as is done when cross 
wind variability is high relative to the cross wind value, any predicted drift time is reset to 9999 prior to 
combining with the other factors and translating to distance. When the individual window constraints are 
used to derive an approach constraint and converted to distance, the value 9999 is treated as other time 
values, and produces a “very large” spacing value that is much larger titan current FAA criteria. Since this 
value indicates uncertainty or lack of knowledge, rather titan an actual prediction of a 9999-second 
residence time, the spacing values must then be limited to maximum values based on current FAA criteria. 
Since AVOSS does not predict where a wake will actually go, but rather calculates a range of possible 
locations given various system uncertainties, the system does not support providing spacing values larger 
than the current criteria. In practice the use of this value had two separate meanings, which caused 
difficulties. A time of 9999 could mean that either the value could not be determined, or that the wake was 
still a factor at the longest time considered. For example an observed drift time of 9999 could result either 
from a wake decaying in only 20 seconds, prior to leaving the corridor, or from a wake that took 3 minutes 
to decay while remaining on the localizer. Future software versions should adopt another technique to 
differentiate between invalid data and factors that cannot be fully quantified but indicate long-lived wake 
times. 


Weather Quality Requirements 

An operational system using AVOSS technology would require self-test and data quality monitoring 
capability. A first approximation to this capability was provided in the demonstration system. The 
operation of a real-tune wake system provided a requirement on the weather system that was not present for 
general scientific use. In scientific wake studies data is reported as it is collected, in that missing data is 
reflected in the data files with missing values. Since AVOSS can create a prediction window at any 
altitude, and since wake predictions must be made at all windows to produce a final output, the weather 
system was required to provide AVOSS data files that had no missing data at any altitude from the surface 
to a minimum height of 600 meters, which was the assumed glide slope intercept altitude. The weather 
system provided this requirement by combining data from several sensors, to fill in altitude gaps that might 
be created by one sensor, and through data interpolation and conservative extrapolation as required. 

Since the data fill-in creates the possibility of making wake predictions that are based on poor weather 
measurements, an automated quality process was implemented. This process required each of the three 
weather file types (wind, turbulence, and thermal) to contain a set of quality flags that described sensor 
health and the weather profile confidence. The AVOSS then tested the data quality and prevented the wake 
predictions from being used to reduce spacing in specific conditions. A Lincoln Laboratory process 
referred to as the AVOSS Winds Analysis System (AW AS), which was able to determine data quality at 
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each altitude region of interest, derived the wind profile. Each file type contains 16 quality flag fields with 
each value an integer. Unused fields were set to zero. 


The quality flags for each file type are: 

Wind Profile Flags: 

1. Percent of altitude levels from 15 through 100 meters that contain data values filled in by the data 
fusion process. Ranges from 0 to 100. 

2. Percent of altitude levels from 101 through 300 meters that contain data values filled in by the data 
fusion process. Ranges from 0 to 100. 

3. Percent of altitude levels from 301 through 600 meters that contain data values filled in by the data 
fusion process. Ranges from 0 to 100. 

4. Percent of altitude levels from 601 through 1000 meters that contain data values filled in by the data 
fusion process. Ranges from 0 to 100. 

5. Percent of South Sodar data points failing AW AS algorithm checks, from 0 through 300 meters. 
Ranges from 0 to 100. 

6. Percent of South Sodar data points failing AW AS algorithm checks, from 301 through 600 meters. 
Ranges from 0 to 100 

7. Percent of North Sodar data points failing AW AS algorithm checks, from 0 through 300 meters. 
Ranges from 0 to 100 

8. Percent of North Sodar data points failing AW AS algorithm checks, from 301 through 600 meters. 
Ranges from 0 to 100 

9. Percent of Radar Profiler data points failing AW AS algorithm checks, from 0 through 600 meters. 
Ranges from 0 to 100 

10. Percent of TDWR wind data points failing AW AS algorithm checks, from 0 through 600 meters. 
Ranges from 0 to 100 

11. Gust fronts or convective storms are impacting the area within 6 tun of the airport center during the 30- 
minute observation period (from ITWS products). No storms = 0, storms = 1 

12. Gust fronts or convective storms are impacting the area within 16 nm of the airport center during the 
30-minute observation period (from ITWS products). 

13. Integer to indicate method of determining wind variance (0 = not defined, 1 = using TKE similarity 
theory, 2 = using radar profiler variance data) 

14. This field was not used, set to zero 

15. This field was not used, set to zero 

16. Data source indicator. Lincoln AW AS process sets to zero (0). North Carolina State University 
nowcast process sets to one (1). 


Turbulence Profile Flags: 

1. 5 meter meteorological tower fluxpac (TO Hz sonic anemometer) data missing (EDR and/or TKE) 

2. 40 meter meteorological tower fluxpac data missing 

3. 3 meter meteorological tower data missing (virtual potential temperature or wind speed) 

4. 10 meter meteorological tower data missing (virtual potential temperature or wind speed) 

5. Last 30-mimnute period valid turbulence profile in use (unable to fix errors and compute an EDR) 

6. Constant turbulence profile in use, using 40 meter EDR and TKE values 

7. Camied turbulence profile in use (insufficient valid data available recently to estimate any profile) 

8. through 15: not used, set to zero 

16. Data source indicator. Observed weather system sets to zero (0). Nowcast sets to one (1). 
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Thermal Profile Flags: 

1 . Ail integer from 0 to 5 indicating the number of valid temperature measurements (altitude levels) from 
the meteorological tower that are used in computing a thermal profile. This value is labeled 
“GoodTower” 

2. An integer from 0 to 9 indicating the number of valid Radio Acoustic Sounding System measurements 
(altitude levels) that are used in the thermal profile. This value is labeled “Good RASS”. 

3. through 15: not used, set to zero 

16. Data source indicator. Observed weather system sets to zero (0). Nowcast sets to one (1). 

From each flag set a status was computed within AVOSS to indicate that the file type was suitable for use. 
The three status words are defined by: 

ATMPRO_Good = [(Flagl < 40 AND Flag2 < 50 AND Flag3 < 60) AND (NOT Flagll)] OR [Flagl6] 
EDATA_Good = [NOT (Flag5 OR Flag6 OR Flag7)] OR [Flag 16] 

TDATA_Good = [(Flagl >= 2) AND (Flag2 >= 4)] OR [Flagl6] 

In the current implementation of AVOSS, only the ATMPROGood status is used to effect spacing. If the 
ATMPROGood status is false, and if a parameter file bit is set to enable the use of the weather quality 
data (which was the mode always used in real-time operations), then AVOSS ignored the wake lateral and 
vertical motion in calculating spacing. In this situation only wake decay is used to reduce spacing. 

IF ((NOT ATMPRO_Good) AND QA_Enable) THEN disable all vertical and lateral wake motion. 

The method used to disable wake motion was to reset any computed vertical or lateral wake residence time 
values to 9999 prior to passing the residence time values to the spacing calculations. The automated 
comparison of wake predictions and observations is inhibited if the predictions were made with either 
ATMPRO_Good or EDATA_Good in a false status. TDATA_Good is computed and logged but is ignored 
during spacing calculations due to the low sensitivity of wake prediction results to temperature profile 
changes 10 . 

The initial criteria for the wind file acceptance also included tests of the individual sensor quality 
indicators. During testing in early 2000, these criteria proved excessively restrictive. In numerous cases 
poor data from one sensor was being filled by good data from another sensor and both the Lincoln 
Laboratory AW AS process and an independent meteorologist indicated that the derived wind profiles were 
accurate, yet the quality process was rejecting the file and eliminating periods of valid AVOSS output. The 
individual sensor requirements were eliminated for the system demonstration. 


Cross Wind Lockout 

Specific logic was implemented to prevent relying on wake drift in low cross wind or highly variable cross 
wind conditions. A cross wind component of about 1.5 to 2 meters/second (3 to 4 knots) can just cancel the 
natural tendency for wakes to separate in ground effect and cause one wake vortex to stay near the runway 
centerline, potentially creating a hazard. A calm wind will allow the wakes to separate as they near the 
ground, possibly creating a calculated aircraft spacing reduction as the wakes rapidly drift out of opposite 
sides of the corridor. This drift scenario could be hazardous to apply, since a slight unexpected momentary 
crosswind could cause a wake to remain on the tunway. Recall that the wind values used for drift 
calculations are a 30-minute mean and a confidence interval based on the crosswind standard deviation. A 
gentle and varying wind could create a mean near zero. 

Another undesirable scenario is that of a significant mean crosswind, that would lead to calculated reduced 
spacing, but with a large variability in the wind. This scenario would be likely in conditions dominated by 
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convective thermal activity, which produce large changes in wind speed and direction as thermals influence 
the measurement location. Application of reduced spacing due to wake drift could also be hazardous in this 
condition due to the possibility of a lull in the wind for a specific arrival that allows the wake to remain on 
the runway. 

Logic was implemented to reduce the likelihood of these scenarios. The crosswind lockout feature 
examines the mean and standard deviation of the crosswind component and calculates the two values 
(Mean - N* Standard Deviation) and (Mean + N*Standard Deviation). The value N is a parameter used to 
establish the size of the confidence interval relative to the standard deviation. The two calculated values 
form the confidence interval used for wake drift calculations. A crosswind lockout threshold (XwindMin) 
was also defined. If any part of the crosswind confidence interval intersected the lockout value range from 
-XwindMin to +XwindMin then the computed wake drift was not used to calculate the wake residence 
time and aircraft spacing. AVOSS used a value of N = 1 and a cross wind lockout of 1 meter/sec for all 
field operations. Therefore any mean wind of 1 m/s or less would prevent spacing reduction due to wake 
drift. With these parameters wake drift could only be used to reduce spacing if the absolute value of the 
mean minus the standard deviation was greater than 1 m/s. For example a 1 m/s cross wind standard 
deviation would require the mean cross wind to exceed 2 m/s in order to use drift to reduce spacing. This 
feature did not affect the use of wake sink or decay in spacing reduction. 


Throughput Calculation 

The spacing criteria calculated by AVOSS were used to estimate the potential runway arrival rate, or 
throughput, that could be achieved. Details of the calculations are described in reference 19. The 
throughput calculation makes use of the top-of-approach spacing criteria calculated, an aircraft category 
mix specified in a parameter file (expected percent of arriving small, large, B-757, and heavy aircraft), 
expected approach speeds for each category, the vertical profile of headwind (to estimate groundspeed), 
and expected ATC controller variance in meeting the prescribed spacing. No interface to the actual ATC 
system is used in the throughput calculation; hence it does not describe actual airport arrival rates during 
periods of AVOSS operation. The throughput calculations essentially determine the average period 
between arriving aircraft weight categories, then determines the relative frequency of each aircraft category 
pair, then determines an expected mean inter-arrival period for the traffic set. This time is then converted 
to aircraft operations per hour. Throughput is calculated with two spacing criteria, the AVOSS provided 
values and the FAA criteria. The difference in these throughput values is used to estimate the performance 
benefit of the AVOSS system operation. 


Wake Prediction Scoring Calculations 

The AVOSS concept calls for a safety monitoring function provided by ground-based wake vortex sensors. 
Detailed development of this safety monitoring logic is dependent on knowledge of the failure modes of the 
wake predictions, the criteria used to define a safe and unsafe event, and the capabilities of the wake 
sensors. To gather information in these areas an initial wake prediction comparison feature was 
implemented. The purpose of this logic was to automate the process of compar ing wake predictions and 
observations, provide feedback on overall system performance, automatically log events that merit analysis, 
and gather insights that would be necessary in the development of an actual safety monitoring function. 

The basic parameter used to define aircraft spacing criteria, and for scoring comparison, is the wake 
residence time in the safety corridor. The predicted behavior is broken down into three wake factors (drift 
out of the corridor lateral limits, sink below the corridor vertical limit, and circulation decay below the 
wake demise definition). The residence time of each factor is computed from wake final exit from the 
corridor, vertically or laterally, or the tune to demise. The residence time for the port and starboard wake is 
the minimum of the residence times of the three factors for that wake. The residence time of the wake pair 
is the time that both the port and starboard wakes are no longer in the corridor, as represented by the 
maximum function in equation 5. 
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A wake residence time can also be determined from the wake sensor data and compared to the predicted 
wake pah residence time. Note that these comparisons are made, within the current AVOSS system, on a 
window-by-window basis. It is very possible, however, that aircraft could not be crossing a particular 
window with the spacing prescribed by predicted wakes at that window for two reasons. One, wake 
behavior at another window may be establishing the overall approach spacing. Wakes my only be a 
constraint at a window for 60 seconds (predicted), but 70-second spacing may be required there to satisfy 
constraints at other approach locations. Second, wake comparisons are made for each aircraft type 
measured for which a prediction is made, yet aircraft spacing prescribed by AVOSS will be based on the 
worst-case wake generated by all aircraft types in a given weight category. For example, an ATR-72 and a 
B-727 are both large aircraft and may have predicted wake residence times of 50 and 70 seconds, 
respectively. AVOSS will require at least 70 seconds behind all large aircraft in this case, so a 60 second 
wake observation from an ATR-72 does not correlate to a specific safety threat. More complex logic 
would be required for a true safety monitoring function to consider spacing that aircraft may actually have 
at a given window rather than only the predicted wake residence time at that window from one specific 
aircraft type. 

The difference between a predicted and observed wake pair residence time is referred to as a “buffer”. A 
positive buffer indicates that the predicted wake residence time was greater titan the observed time. A 
negative buffer indicates that the observed wake residence time was greater titan predicted. A negative 
buffer is also referred to as an “exceedance”. As suggested above, an exceedance may, but does not 
necessarily represent a situation that would have led to a wake encounter. Rather it indicates an event 
requiring analysis to diagnose system error modes and required improvements. The exceedance may 
indicate that the wake pair may not have been fully out of the approach corridor or fully decayed if another 
aircraft had been flying the prescribed spacing. An exceedance may also indicate some other aspect of 
system operation that requires analysis. In general, differences between predicted and observed wake 
residence times have at least four components: 

Diff = Diff IC + Diff wx + Diff PRED + Diff SENS0R (7) 

Where 1C represents a component of difference due to wake initial conditions, WX represents a contribution 
due to wake weather conditions different than expected, PRED represents a contribution due to the 
predictor algorithm not adequately modeling all relevant factors, and SENSOR represents a contribution 
due to sensor measurement errors. Examples of each component are 

1. IC: An aircraft conducting a visual approach may be well above glide slope or to the side of the 
localizer, changing the time that the wake remains in the corridor. 

2. WX: Frontal passages or other factors may create different than expected wind or turbulence 
conditions at the wake location. 

3. PRED: The wake behavior may not be fully described by the wake prediction algorithms, for 
example reduced sink rate due to vertical wind shear. 

4. SENSOR: Difference between actual wake behavior and sensor measurements, such as a sensor 
inadvertently combining two aircraft arrivals into one wake track or failure to terminate tracks at 
wake demise due to atmospheric turbulent eddies. 

The initial attempt to develop a comparison algorithm 19 simply took the observed residence time of each 
wake from the wake sensors and applied equation 5. This simple approach failed due to several factors: 

1. If the wake factor that set spacing was not observed by the sensor, then the factors that were 
observed led to a calculation suggesting a poor prediction, even when the observed wake behavior 
was essentially identical to that predicted. For example a wake may sink below the corridor floor 
in 15 seconds at the wind line location but require 70 seconds to drift laterally from the corridor. 
The wind line did not quantify sink time, leading to calculated prediction errors on the order of 55 
seconds when the wake acted as predicted. 

2. The wake sensors in use frequently did not track both wakes long enough to quantify a residence 
time for both wakes. The current criteria in use for declaring a residence time for any factor 
required positive observation of the wake outside the corridor limits or at a circulation value below 
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the demise value, not simply the absence of a wake detection within the corridor. Both the wind 
line and the CW lidar would frequently not track the most rapidly drifting wake, and all sensors 
would sometimes lose tracks prior to the wake decaying below the defined demise value or exiting 
the corridor. Limitations of the sensors and the criterion for declaring an observed residence time 
led to a situation where many wake sensor data files were not usable for comparison puiposes. 

3. Many comparisons were being made in domains where the wakes were persisting for periods of 
time much less titan operationally feasible aircraft spacing (i.e., 10 to 30 second residence times). 
Inclusion of these events can complicate interpretation of prediction errors in domains that are 
operationally significant (i.e., 50 to 80 second wake residence time). 

The wake comparison logic was modified to address these problems. Two changes were made to 
accommodate the sensor limitations relative to the validation criterion and allow more observed events to 
be scored. One was to break the events into categories called Class 1, Class 2, Class 3, and Class 4. Class 
1 are the events where both the predicted and observed wake pair residence time was less than a minimum 
time (TauMin). TauMin was set to 50 seconds for AVOSS operations and represents an expected lower 
bound on actual aircraft spacing given a typical runway occupancy time on the order of 45 seconds. Class 
1 events indicate that the wake vortex was not a constraint to that aircraft operation. Class 2 events are 
counted if both the predicted and observed wake residence tune was greater than a value TauMax. TauMax 
was set to 180 seconds and represents an expected upper bound on separation using current FA A spacing 
criteria. These events indicate that AVOSS has no potential to reduce spacing. No Class 2 events were 
detected during AVOSS operations. Remaining events (class 3 and 4 described below) are those where the 
buffer is negative and wake residence time falls between minimum aircraft spacing due to runway 
occupancy and current criteria. It is in this domain where wake prediction errors are potentially hazardous. 
In this domain prediction buffers are calculated as a diagnostic tool for system refinement. 

When the wake sensor data does not quantify the same wake factor used to establish spacing criteria, a 
buffer computed from that data is considered '‘soft”. This is a class 3 event. For example if the residence 
tune is 15 seconds at a given approach window due to wake sinking, but the sensor only quantifies a drift 
time of 60 seconds (does not quantify the actual vertical residence time), the resulting calculated 
exceedance of 45 seconds is considered soft, since it may or may not represent an actual case of a wake 
persisting in the corridor longer than predicted. It is not possible to determine from sensor data in this case 
if the wake actually sank as predicted. When the sensor does observe the same factor then the calculated 
buffer is considered “hard”, indicating a high confidence in the wake comparison. These hard buffer events 
are considered class 4. 

A second major change was to determine if an observed wake event could be used for scoring if only one 
of the two wakes was quantified. Generally, when the sensors could only track and quantify one wake, that 
wake was usually the slowest moving, or the wake most critical to quantify for following aircraft to the 
same runway. A test was implemented for these cases that performed a least-squares fit to the wake lateral 
position time history data in the wake sensor file to determine drift rate. If the single quantified wake was 
drifting in a maimer to suggest that the other wake must have had a shorter lateral residence time, then the 
observed wake was considered the “critical wake” and the data file could be used for scoring. The test 
required that the observed wake drift in a direction towards the runway centerline at a rate of at least 1.0 
m/s (2 knots). This drift condition indicates that the wakes are being effected by cross wind in a manner 
that will cause the unobserved wake to vacate the corridor in less time than the observed wake. If this test 
is failed then there is no certainty that the unobserved wake vacates as quickly as the observed wake, and 
both wakes are considered critical. When both wakes are critical then both must be quantified to allow the 
data to be used to score predictions. Note that only the wake drift is considered in this critical wake test. 
The nature of the current wake predictor algorithm is such that both wakes sink and decay at nearly the 
same rate in all weather conditions, so quantification of these factors for either wake is sufficient for 
scoring sink and decay. Once the wake predictor is enhanced in the future to predict differential sink and 
decay rates due to vertical cross wind shear, the current critical wake logic will require modification, unless 
it is no longer required due to unproved sensor performance. Note that the calculation of hard and soft 
buffers is an artifact of the relationship of two factors, the limitations of the available sensors to reliably 
quantify residence tune for both wakes and the philosophy that absence of wake detection in the corridor is 
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not sufficient to declare a residence time. Division of observations into soft and hard would not be 
desirable for an operational system. 


There are special situations handled by the revised comparison logic. In particular when wind line data is 
used all buffers are soft, and the predicted wake residence time is recalculated using only wake drift prior to 
calculating the wind line buffer. Since wind line data could not be used to derive vertical residence time or 
demise time at that location, the revised logic allowed the wind line to be used solely for verifying drift 
predictions. Due to a large volume of wind line data, these buffers are useful for diagnosing the ability of 
AVOSS to quantify cross wind statistics and the resulting drift behavior. 

The current AVOSS comparison algorithms do not represent a true safety monitoring function, but rather a 
system diagnostic tool. The log of exceedance cases ( Appendix C) provides a list of events deserving of 
analysis. During interpretation it is important to avoid assuming that comparisons reflect only wake 
predictor output and “truth” as provided by the wake sensors. As noted above numerous factors can create 
differences between predicted and observed wake behavior. Trends or systematic characteristics of the 
exceedances should be exploited to suggest refinements to specific subsystems or changes to system 
criteria or even architecture. For example, if a large fraction of exceedance events occurs due to wake 
demise at low altitudes, then attention should be placed on verification of turbulence measurements, wake 
decay prediction algorithms, and sensor algorithms that determine when to terminate a track and when 
background atmospheric turbulence can be confused with a vety weak wake. Any trends for exceedances 
to occur in specific weather domains or times of day would also suggest processes for phasing the AVOSS 
into operational use, that is the system would not initially be used in the domains leading to low confidence 
predictions. 

Figure 6 shows flowcharts for the current wake comparison logic, taken from software specifications and 
slightly modified for readability. Prior to comparing wakes sensor data to predictions, the Compare code 
verifies that a prediction has been made in the past 35 minutes and that the prediction was made while the 
weather file quality flags indicated valid wind and turbulence data were used in those predictions. Next the 
wake data file is examined to determine which of the two wakes may be deemed critical, or if both wakes 
are critical, and then the wake residence tune is computed from the individual components provided in the 
wake file. Next, two tests are applied to determine if the wake file is useful for scoring. First, the critical 
wake (port, starboard, or both) must not have a residence time value of 9999, that is, the sensor must have 
quantified a valid residence time for those wakes that would constrain spacing for following aircraft. 

Second the aircraft type observed by the sensor and the location of the scan (in the runway coordinate 
system) must match predictions made by AVOSS. The aircraft database used in the field consisted of 19 
aircraft types that included the types most common at DFW. 

Summary 


A ground-based system has been developed to demonstrate the feasibility of automating the process of 
collecting relevant weather data, predicting wake vortex behavior from a data base of aircraft, prescribing 
safe wake vortex spacing criteria, estimating system benefit, and comparing predicted and observed wake 
vortex behavior. This report has described many of the system algorithms, features, limitations, and 
lessons learned, as well as suggested system improvements. The system has demonstrated concept 
feasibility and the potential for airport benefit. Significant opportunities exist however for improved 
system robustness and optimization. A condensed version of the development lab book is provided along 
with samples of key input and output file types. This report is intended to document the technical 
development process and system architecture, and to augment archived internal documents that provide 
detailed descriptions of software and file formats. 
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Appendix A - Suggested System Improvements 


Lessons learned from AVOSS operations suggest numerous considerations for future implementations. 
Some considerations deal with system architecture or philosophy, others with implementation details. 

System Philosophy Considerations 

A major issue that cuts across several areas of system design is the definition of wake vortex demise. A 
demise definition is needed both for the AVOSS internal algorithms that examine wake predictor results to 
search for a demise time, and for wake sensors as a minimum design requirement and a track-termination 
criteria. Compar ison of current FAA spacing criteria to typically observed decay rates 20 was made to 
determine the wake strengths that may be encountered today with current spacing rules and an assortment 
of large and heavy generator aircraft at approach speed. The analysis indicates that current rules will 
prevent small aircraft from encountering wakes stronger than about 100 m 2 /s with worst-case generator 
aircraft, which is about the strength of the wake generated by a turboprop commuter aircraft, with 
encounters behind most aircraft weaker than 30 m 2 /s. Large and heavy aircraft that are following current 
spacing criteria may encounter much str onger wakes. The large aircraft may encounter wakes of about 100 
m 2 /s behind the average generator and up to 200 m 2 /s behind worst-case generators. Heavy aircraft may 
encounter wakes of 200 to 300 m 2 /s behind other heavy aircraft. For comparison the wake generated by 
large aircraft such as the B-727 range from 170 to 270 m 2 /s between minimum and maximum landing 
weight. Sensors in use during the AVOSS project could typically detect wakes as weak as 100 m 2 /s, with 
slightly weaker wakes being detectable in very calm conditions. In windy conditions wakes may be lost at 
strengths around 120 m 2 /s and attempts to track weaker wakes may lead to false wake detections from 
atmospheric turbulence. 

Conservative industry input suggests that there is no wake strength that can be safely encountered, i.e., zero 
strength. This value poses system design problems, as theoretically wakes may never decay to zero, and 
sensors cannot be designed to detect near-zero strength wakes to quantify that decay time. The current 
AVOSS approach is to never reduce spacing for small follower aircraft due to wake decay, since existing 
sensors cannot track all wakes that are significant to small aircraft. For large and heavy followers a demise 
definition is established that determines when the wake strength has essentially weakened to a level no 
greater than commonly encountered atmospheric turbulence and is below the strength that may be 
encountered with current FAA criteria. For AVOSS operations to date the demise definition has been 
circulation strength of 90 m 2 /s. Even with this value for demise, the sensors in use may have difficulty in 
accurately tracking wakes and determining when to terminate a track and declare demise as the wake 
strength becomes comparable to atmospheric turbulence and circulation estimation noise becomes large 
relative to the wake strength. 

The total AVOSS system will become more robust when a consensus can be reached on an acceptable 
demise definition for large and heavy aircraft, not for intentional encounters but as a value that will be non- 
hazardous and will not require a go-around maneuver if inadvertently encountered. The wake sensors and 
prediction system can then be optimized to determine when wakes have decayed below this threshold. 
Consideration should be given to thresholds that are dependent on the category of the follower aircraft and 
are compatible to the circulation strengths in today’s environment, about 100 nr/s for large aircraft in trail 
and 200 m 2 /s for heavy follower aircraft. Values of this magnitude are consistent with flight safety and 
current flight rules, provide a more robust target for sensor tracking, and will improve system spacing 
performance. Absence of an industry standard definition of demise may actually decrease safety, as the 
past practice tends towards avoidance of any wake that can be measured. Without minimum performance 
standards the minimum measurable wake is sensor-dependent and may be greater than the proposed values. 

Closely coupled with the demise definition is the criteria used to declare wake residence time by the 
sensors. The approach used was to require the sensor to observe the wake actually drifting or decaying 
through the corridor or demise limits. This approach was taken for two reasons, to ensure that sensor 
failure or degraded detection perfonnance could not lead to a false indication that the corridor was safe and 
also to provide a definitive time for the drift and demise residence time factors for predictor validation. 
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The alternative to this approach is to declare the corridor safe when the sensor can no longer detect a wake 
within it. The approach used requires the sensor to track both wakes long enough to determine residence 
times. Very frequently however, a wake could not be tracked for this length of time. For example demise 
tune was often not available when the wake vanished before reaching the demise value. This could occur 
for numerous reasons, including drift beyond the sensor range, rapid decay between scans of the lidar 
systems that caused the wake to decay from above demise to an undetectable value before the next scan 
sweep, or difficulty in tracking wakes near the demise value due to atmospheric turbulence. Likewise a 
wake that decayed before exiting the corridor led to indeterminate “9999” values for the drift or sink 
residence times. In some cases the downwind wake would drift away so rapidly that the wake sensor never 
tracked it. The end result was a large fraction of wake observations unusable for predictor scoring as well 
as special logic within AVOSS to maximize use of marginal observations. 

The approach of declaring the corridor safe when the wake cannot be observed is much less demanding of 
the sensor but leads to strict reliability and probability of detection requirements on the part of the sensor. 
There must be a very high probability that lack of wake detection is due to a lack of a wake rather titan 
inadequate sensor minimum performance, extremely dry and clear air that compromises lidar detection, or 
any other factors. With appropriate minimum performance specifications, well understood sensor failure 
modes, self -testing, and reasonable wake demise definitions, consideration can be given to allowing sensors 
to declare a residence time, or corridor safe, when no wake is observed. Sensor design and safety 
monitoring logic within AVOSS may be greatly simplified if robust detection is assured. 

Another significant system philosophy enhancement would be a stronger probabilistic basis for wake 
prediction and risk management. The system currently considers wind statistics in determining a 
confidence interval on wake drift rates and aircraft flight technical error statistics for sizing the safety 
corridor. Discrete logic is used in domains where the statistical process may break down, for example the 
low cross wind lockout logic for wake drift use. However the wake predictor and the corridor residence 
tune logic use relatively simple discrete logic for risk rather titan a statistical process. The wake predictor, 
given a description of the weather, will provide a wake trajectory with no statistical description of the 
confidence of that prediction. AVOSS runs the predictor multiple times per aircraft prediction, using the 
wind confidence interval to vary the weather inputs, to estimate the potential range of wake motion. The 
function of estimating wake uncertainty was only implemented for uncertainty in the crosswind, not for 
turbulence or thennal gradient uncertainties. Expectations and later analysis 11 ’ both suggested that wake 
spacing is more sensitive to the cross-wind than to the other parameters, and cross wind is more likely to 
change significantly over short periods of tune than ambient turbulence or thermal gradients. Although this 
approach worked well in system operation 9 , it possesses limitations. First, the inherent uncertainty in the 
wake prediction algorithm itself is not quantified. Given multiple runs with identical initial conditions and 
weather conditions, the wake predictor will always produce identical outputs. Field observations of wake 
behavior in nearly identical conditions will produce a small range of behavior (decay time or motion rates). 
Variation in wake behavior, particularly sink rate, increases as atmospheric turbulence increases, or 
convective activity or thennal inversions create vertical wind shears. Noimal wake behavior, such as the 
sinusoidal shape taken by a wake pah due to the Crow instability, can create small variations in wake 
altitude or lateral position relative to the mean position when a sensor randomly samples the wake system. 
Current predictor algorithms are not able to provide a quantifiable bound, or confidence interval, on the 
wake altitude, lateral position, or strength. Ideally the predictor could accept a description of the weather 
and provide information at each time step to indicate the confidence in the prediction. For example the 
lateral and vertical position may be provided as a mean and a standard deviation. Turbulent conditions, 
known to make sink rate estimation less reliable and sometimes slow the wake sinking motion, might 
increase the confidence interval as well as slow the predicted sink rate. The wake predictor might describe 
the Crow instability as an increasing position standard deviation over time. Such a statistical wake 
predictor would simplify the system logic and be more easily adaptable to formal risk analysis methods. 

Another limitation of the current spacing criteria method is that it is single-dimensional, in that the 
uncertainty of one wake factor at a time, such as drift, is calculated. When extended to multiple factors 
(drift and sink for example) the results may be overly conservative. This hypothesis is made from 
observation that temporary weather conditions that may create worst-case behavior in one factor may tend 
to provide benefits in the other factors. For example, a temporary cross wind shear that reduces wake sink 
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rate requires a cross wind, which will move the wake away from the localizer. A lull in the wind that may 
allow the wake to remain on the localizer in turn will not be accompanied by a cross wind shear that could 
prevent wake sinking. Wake residence time confidence intervals should be estimated based on the 
interdependency of all wake factors and the probability of an encounter, while the current method would 
combine worst-case tunes from an independent assessment of each factor. 

The use of the corridor to determine residence time would be enhanced with a statistical approach that 
considered contours of risk rather than the current binary risk/no risk method, figure 7. Currently a wake is 
either inside or outside the corridor, and a wake that has drifted to the edge of the corridor carries the same 
risk weight within AVOSS as a wake on the aircraft path. Many of the exceedance cases logged in field 
tests involved wakes that had near ly drifted out of the corridor. These exceedance cases carry the same 
weight as a wake that remains on flight path, yet an aircraft encounter would not have occurred unless the 
aircraft had a large (3 standard deviation) flight technical error in the direction needed to reach the wake. 
The binary risk model used has also impeded the definition of a demise definition, since a wake that has not 
left the corridor is assumed to car ry an encounter probability of 1 , while in reality the encounter probability 
is much less. Obviously the wake strength permitted for an encounter probability of 1 will be much less 
than for an encounter probability on the order of 1 0 or 10 6 . Consideration should be given to defining a 
probability of a significant encounter, which involves wake strength and position as well as the flight 
technical error of the aircraft, and designing AVOSS to determine spacing values to meet specific 
probabilities. A model for the next system design might therefore result from a formal system risk analysis 
of the current system. Figure 7 shows this approach. The encounter probability can be determined from 
the probabilities of lateral and vertical positions coinciding with the aircraft location, and the probability of 
no demise. Each of these probabilities will reduce as time increases and the system could be designed to 
determine the time for a given probability, without the need for a defined corridor shape. If the 
probabilities of the three factors are not independent, as suggested by field experience, then the calculation 
can be done on a domain-by-domain basis. For example the crosswind shear conditions leading to 
increased wake vertical position uncertainty will tend to reduce the lateral position uncertainty. 

Implementation Considerations 

Within the current system philosophy numerous enhancements would improve system operation. One of 
the most significant would be wake sensor upgrades to state -of-tlie-art systems. The lidars in use had a 
research heritage and were roughly 4 to 6 years old at the AVOSS demonstration. This represents a 
considerable gap in both laser technology and digital signal processing capabilities. The scanning 
capabilities (pulse repetition frequency, range bin size) of the AVOSS lidars led to long gaps between lidar 
hits, typically 10 seconds or more between laser sweeps past the wake and larger than optimal uncertainties 
in the wake position at each hit. This tune interval was adequate for a wake to significantly decay or vanish 
between measurements, complicating demise time determination. The wake data collected had sufficient 
frame-to-frame noise that curve fitting processes had to be used to smooth the track and decay histories. 
These curve fits introduced other potential error sources, possibly not properly reporting a wake rebound 
from the ground or curve fits to a few noisy data points leading to unrealistic decay or motion data plots. 
The scan capabilities of current systems also compromises wake detection of departing aircraft. Due to 
wide spatial dispersion of aircraft shortly after liftoff, a large area of the sky must be scanned to acquire the 
wake. Slow scan rates can lead to first detection up to 30 seconds after passage, and no second detection 
due to decay between scans. Systems currently available' 11 have improved scanning capabilities and can 
produce high quality wake tracks with position updates roughly every 5 seconds. These improved 
capabilities create the potential to eliminate curve fits to the data and enhance the ability to hack both 
wakes and accurately determine residence time. 

The wake lidar also presents an opportunity for simplification of the weather system. Lidars can provide 
high resolution and high update rate cross wind data within the arrival or departure corridor, at the altitude 
of interest. Atmospheric turbulence data (turbulent kinetic energy and eddy dissipation rate) have been 
measured also by lidars and particularly validated with in situ measurements. In 1998 a simplified AVOSS 
was operated using only lidar wind and turbulence data. Lidar wind data was not used within the DFW 
weather system since year-round AVOSS operation (weather and spacing predictions) was desired and the 
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lidars were only deployed for a few weeks per year for full system tests. While the lidars were not 
deployed the AVOSS operated with dedicated weather sensors and a single wind line for wake data. 

The time required to drift out of the lateral limits of the safety corridor was calculated from a cross wind 
confidence interval computed from the mean and standard deviation of the cross wind. The 30-minute 
mean and standard deviation were computed from a series of 30 1 -minute cross wind measurements. The 
system performance, both throughput and exceedance counts, were sensitive to the multiplier applied to the 
standard deviation, hence the confidence interval used. Additional analysis is in order to determine (a) if 
other methods of estimating the wind confidence interval produce better results (for example a percentile 
cross wind represented by the 30 individual 1 -minute values) or (b) if modifications to the corridor are 
appropriate (for example an inner corridor with high criticality and an outer corridor with a higher allowed 
probability of wake presence). 

The weather system was designed initially as a resear ch system, with inclusion of all sensors that were 
believed to be needed to avoid missing critical signals. Considerable opportunity exists to eliminate 
sensors for a more economical installation, particularly if the wake lidars are employed as weather sensors. 
Two separate weather systems were used, a local system at Dallas using ground based sensors, and a 
planetary boundary layer model 2 for short-term “nowcast” predictions of all weather parameters. The in 
situ system was used for all wake vortex spacing criteria outputs and the nowcast system was used to 
predict future runway acceptance rates for planning purposes. The nowcast model was operated by North 
Carolina State University, using operational weather products from the National Center for Environmental 
Prediction for initialization. Although the nowcast model used no in situ sensors at DFW for initialization 
or correction, wind estimation accuracy was typically within 1.5 m/s (3 knots) of observed winds with 5 to 
10 hour old forecasts. This accuracy is not adequate for use near the ground, where critical cross wind 
values are typically on the order of 1 or 2 m/s and small changes in cross wind have large effects on wake 
motion. The nowcast model may be adequate however for use above ground effect where wake drift is not 
effected by the ground and is less sensitive to small cross wind changes, wake drift is less of a factor in 
spacing than sink rate, and where current ground based sensors have the most difficulty in providing robust 
data. Limited manual comparisons of sensor observed winds aloft (fused from multiple sensors) and 
nowcast winds aloft suggest that the accuracy of the two systems is similar at altitudes above about 200 
meters. Although the demonstrated weather system was adequate to realize some initial system benefit in 
limited weather domains, significant opportunity exists to improve wind estimation, vertical profiling, and 
sensor cost reduction by blending the observed and nowcast systems, along with wake lidar wind data and 
perhaps downlink of aircraft data for validation. The nowcast data could also be used to predict changes in 
the observed weather profile. Currently data taken for a 30-minute period is used to estimate weather 
statistics for the next 30 minutes using persistence. In general this approach worked well and wake spacing 
changes were typically small from one thirty-minute period to the next in the absence of major weather 
changes. The nowcast could be used to improve the persistence forecast further when conditions are 
changing. Such blending is non-trivial, however, and would require a significant field presence to test and 
refine algorithms with significant data sets at all times of the year. 

Other implementation enhancements include modifying the use of the value 9999 for invalid data, as 
mentioned earlier and developing true safety monitoring logic. Lessons learned from the current wake 
scoring software would be needed for the safety monitor function, which would run in parallel with more 
detailed scoring software for diagnostics purposes. Safety monitoring might not consider deviations from 
observed and predicted wake behavior as much as it might consider deviations between observed wake data 
and actual aircraft spacing being provided. For example a B-737 predicted residence tune at a window may 
be 30 seconds and the observed may be 60. This would not be a safety issue if other windows or another 
large aircraft in the database were requiring 70-second spacing at that window. The safety logic must also 
anticipate wake exceedance events in order to provide adequate notice in the rare event that a go-around is 
required. This could be performed by also comparing observed weather to that used in the wake 
predictions. For example a sudden lull in the winds when the prediction was for a steady crosswind would 
also indicate that wakes will not be drifting as predicted. During the wake calculation process AVOSS 
could quantify and provide weather values that would require caution alerts to ATC. 
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Appendix B - Aircraft Database and Parameter File 

The aircraft data required to run AVOSS is stored in a disk file named “ac dbase.acd”. The data base used 
for DFW field operations is presented below. The file contains two comment lines, denoted by the initial 
character “#”. The second comment provides a key to the fields provided for each aircraft. All units are 
metric. The third line provides the expected maximum speed (m/s) on final approach for the small, large, 
and heavy category aircraft, respectively. These values are used only for computing the required top-of- 
approach spacing given the spacing required at individual approach windows. The next line contains the 
number of aircraft in the database and is used by the file reader to increment the loop that reads data. If 
more aircraft are listed than indicated by this line then they are not read or used for wake predictions. 

The remaining lines each provide the data required for one aircraft type. This data is used to initialize the 
wake predictor algorithms and to match wake predictions to sensor observations. The first field provides 
an aircraft identification that is matched to an equivalent wake sensor data file field to enable scoring of 
predictions. The second field provides a common name label for the type, including variants that are 
considered similar for wake predictions. Field two is not used by the machine, Field 3 indicates if the type 
is considered large “L”, a B-757 '‘B", or a heavy aircraft “H”. This field is used when combining spacing 
criteria for each aircraft type into a category-based matrix. The final three fields provide wing span 
(meters), estimated maximum landing gross weight (kilograms), and estimated approach speed (m/s). The 
data is intended to represent the aircraft types most common at DFW as well as worst-case types in each 
category. For example the ATR-72 is a worst-case large aircraft with respect to wake sink rate, due to a 
large whig span relative to the strength of the generated wake and the B-727 is one of the heaviest aircraft 
in the large category. 

#Aircraft data set 

#AC_ID, AC_Type, Category, Span, Max_LD_GW, Est_APP_Speed 

65,75,82.4 
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AT72, ATR-72 ,L, 27 . 1, 19913,61.8 

FK10 , Fokker F100 , L, 28 . 1 , 44453 , 69 . 5 

DC9 , DC- 9 , L, 28 .5,49896,69.5 

B737,B737/73F/73J/73S,L, 28 . 9, 54432,72 . 1 

MD80,MD80/83/88/90, L, 32.9,58061,69.5 

EA3 2 , A3 2 0 , L , 3 3 .9,64502,74.6 

B727, B-727, L, 32. 9, 72576, 72.1 

B757,B757,B,38 . 0, 89813, 69 .5 

DC8 , DC- 8 , H, 45.2,113400,72.1 

EA3 1 , A3 1 0 , H , 4 3 .9,12 3016,72.1 

B767,B767,H,47.6,126101,74.6 

E A3 0 , A3 0 0 , H , 4 4 .8,137985,74.6 

L101,L-1011,H,47.3, 166925, 77.2 

EA3 4 , A3 4 0 - 2 0 0 , H , 60.3,180986,69.5 

DC1 0 , DC- 1 0 , H, 50 .4, 182801, 72 .1 

MD11 , MD- 11 , H, 51.7,195048,77.2 

B777,B777-200,H, 60. 9, 206388, 72.1 

B747, B747- 100/2 00/3 00 ,H, 59 . 7, 265356 ,77.2 

B74F, B747-400 ,H, 64.3,285768,82.4 

Many AVOSS run-tune options are controlled by a parameter file named pfile.prm. The file begins with 
any number of comment lines, denoted by “#”. Following the comments lines is a description of the data 
fields. This was provided as a reference to minimize the chances of error when modifying parameters in 
the field. Following the field descriptions are the actual parameters used by AVOSS. The example file 
below shows the values used by AVOSS at the DFW field site. 

The corridor option was used to select one of two corridor floor options, as described in reference 18. 

N Sigmas is a multiplier to apply to the cross wind standard deviation when estimating the bounds on wake 
drift behavior. SINKPCNT is used to reduce the effective sink rate of the predicted wakes when 
calculating spacing. For example if the wake predictor estimates a wake to sink below the corridor floor in 


19 



15 seconds, and SINKPCNT is set to 50, then the residence time applied becomes 30 seconds. This value 
was set to 100 except during sensitivity studies. TIMEADD was also implemented for sensitivity studies. 

It provides a constant bias (addition) to computed wake residence times and was set to zero for field work. 
Both SINKPCNT and TIMEADD were included to test techniques for accommodating wake prediction 
uncertainties. Demise Def and Demise VAL are wake circulation values (m 2 /s) used to estimate demise. 
The first value is used by the spacing calculations and is normally set to 90 m 2 /s. Since the wake sensors 
frequently cannot track wakes of this low strength, a higher value can be used for scoring predictions. For 
example if DemiseVal is set to 120, then AVOSS compares the predicted and observed time for wakes to 
decay to that value. The value UPDATE PERIOD is not used within AVOSS 

The NUM TRACK WRITE field is used to control writing of wake predictor outputs (wake motion and 
decay time histories) to disk. These files are quite large and in general are only needed for plotting wake 
lidar data against predictions. Each track file contains all wake track predictions for all aircraft at a given 
window. With 19 aircraft and up to three wake predictions per aircraft, each file contains up to 57 wake 
tracks. This line contains a number that indicates the number of windows to write, followed by a list of the 
window numbers. The default windows created at program execution are numbered 0 through 5 and any 
additional windows begin with the number 6. 

The next four' lines contain flags used to disable specific wake factors in calculating spacing. The output 
spacing file (Appendix C) contains an “upper set” of spacing values and a “lower set” of values. The upper 
set ignores wake demise, that is, only uses wake drift and sink to establish spacing. The flags 
Disable Lat Upper and Disable_Vert_Upper also allow the user to switch off the consideration of wake 
drift or sink, respectively. With all factors disabled the upper spacing values provide the current FAA 
spacing criteria. That setting is run by default so that AVOSS will compute throughput with the FAA 
criteria and hence the performance benefit with reduced spacing. The flags for the lower set provide the 
same function for the lower set of spacing matrices. With both flags set the only factor considered in the 
lower matrix set would be decay. 

Taumin and Taumax provide the time values required by the wake comparison algorithms to determine if 
an observation is a Class 1 or 2 event. QA_Enable determines if AVOSS will use the weather quality 
assurance process when computing spacing. If disabled, spacing will be computed regardless of the 
weather data quality. QA_Enable was always enabled in the field. P_Version and Batch are not read by 
AVOSS. Path was used to direct AVOSS output to a specific disk area. The current shell code ignores 
Path and directs the output as needed. 

Runway lD is a character string that labels the runway in use. This string is used within AVOSS when 
building output file names. Future version of AVOSS may run independent predictions for different 
runways and this field would provide a means to select the appropriate wind files, which are specific to the 
runway orientation, and label outputs. The airport elevation data is not currently used within AVOSS. All 
calculations and weather files are with respect to altitude above ground. 

The next three fields directly effect the AVOSS corridor dimensions by providing the point where the glide 
slope intercepts the runway, the glide slope angle, and the altitude above ground that the aircraft are 
assumed to intercept the glide slope. The glide slope is assumed to intercept the runway at -305 meters 
(about 1000 feet down the runway, on the negative X-axis), the glide slope angle is 3 degrees, and the 
aircraft are assumed to intercept the glide slope at 600 meters (1968 feet) above ground. 

The next four fields provide the fractions of small, large, B-757, and heavy aircraft in the traffic mix and 
must sum to 1. In current FAA spacing criteria the B-757 is essentially its own class when it is the 
generating aircraft, and is considered a large aircraft when in trail. The ATC rounding interval rounds 
spacing outputs to specified nautical mile intervals before estimating throughput. For example an AVOSS 
output of 3.38 miles may be rounded to the half-mile prior to throughput estimation, on the assumption that 
ATC controllers could not make use of any finer criteria. The ATC variance value of ten seconds is used 
also in the throughput calculations, as described in reference 19. 
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Finally the list of additional windows is given. The file reader assumes that this data is last in the file. The 
fust number is the number of additional windows, flowed by the X-axis location of those windows. 
Typically new windows are added to provide wake predictions at the locations of wake sensors. For 
example at DFW in 1999 and 2000, the continuous-wave lidar was scanning at X = 84 meters (near 
threshold) and the pulsed lidar could scan at 1080, 1702 or 2262 meters by changing scan azimuth. Future 
systems might also use this capability to adapt to specific meteorological conditions, for example to place a 
prediction window at a glide slope location likely to be affected by a strong cross wind shear or thermal 
inversion. 

# Parameter file for AVOSS Version 2, format modified July 1999 

# 

# Program Control Information 
Corridor_Option (integer) 

N_Sigmas (integer 1,2,3) 

SINKPCNT (% of avg. sink rate to use in establishing spacing. 0 to 100) 

TIMEADD (is a constant time bias to be used before computing spacing) 

Demise_Def (integer meters squared per second, for spacing calculation) 
Demise_Val (integer meters squared per second, for validation) 

XJpdate_Period (integer minutes for refresh of separation matrices) 
NUM_TRACK_WRITE (number of track files to write followed by window number (s) to 
use ) 

DISABLE_LAT_XJPPER (1 to disable lateral spacing for upper output matrices) 
DISABLE_VERT_UPPER (1 to disable vertical spacing for upper output matrices) 
DISABLE_LAT_LOWER (1 to disable lateral spacing for lower output matrices) 
DISABLE_VERT_LOWER (1 to disable vertical spacing for lower output matrices) 
TAXJMIN (minimum time for wake buffer calculation, simulates ROT) 

TAUMAX (maximum time for wake buffer calculation, simulates max spacing) 
QA_Enable (1 to enable QA, 0 to disable) 

P_VERSION (For later use to select versions of the predictor algorithm) 

Batch (0 to run batch, 1 to run real-time data) 

Path (path or string "UNIX" for file output) 

Runway_ID ( char ) 

Airport_Elevation (real, meters) 

Glide_Path_Intercept_on_Runway (int, meters) 

Glideslope_Angle (real) 

Glideslope_Intercept_Altitude (integer, meters, AGL) 

FRAC_Small (fraction of throughput in small category, must be between 0 and 1) 
FRAC_Large (fraction of throughput in large category, must be between 0 and 1) 
FRAC_B757 (fraction of throughput in B757 category, must be between 0 and 1) 
FRAC_Heavy (fraction of throughput in heavy category, must be between 0 and 1) 
ATC_Round_Interval (spacing rounding interval (NM) used in the throughput 
calculations ) 

ATC_Var (ATC variance) 

Num_Extra_Windows (to add to defaults, follow with list of integer X values) 

2 

1 

100 

60 

90 

120 

30 

3 3 6 7 
1 
1 
0 
0 

60 

120 

1 

3 

0 

/ export /home/ adam/ avoss/avoss_v2 .4.0/ data/cemp_data/ 
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R17C 
183 . 6 
-320 
3 . 0 
600 
0 .25 
0 .60 
0 .10 
0 . 05 
0 .5 
10 

3 84 1080 1702 2262 
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Appendix C - Output data files, Spacing, Log, Statistics, and Exceedance 


Several output file types ate discussed. Figure 1 shows the software modules that create each file type 
discussed. The core code writes a spacing file and a log file. The code that compares wake predictions and 
observations, which resides just outside the core, writes a statistics file and an exceedance file. Batch 
programs exist to allow the core and the comparison code to be ran together with archived weather and 
wake sensor data files. 

The output spacing criteria are provided in one file per 30-minute period. A typical file name is 
“DIST R17C.991201 010000". All spacing file names begin with DIST, followed by the runway 
identification from the parameter file, then date and time in YYMMDD HHMMSS format. The files begin 
with an arbitrary number of comment lines, each beginning with “#”. These lines are used to describe the 
file contents. The data begins with a line that repeats the runway identification, year, month, day, hour, 
minute and second. The next line echoes the corridor option number, N Sigma, the DemiseDef, and the 
number of aircraft in the database. The next line echoes the QAEnable flag, the QA status of the three 
weather files that made up the prediction, and weather flag 16 which indicates if the weather was derived 
from the sensors at DFW (flag = 0) or from the nowcast system (flag = 1). The fourth data line echoes the 
data used to estimate railway throughput, that is, the fraction of each weight class, the rounding interval, 
and the ATC variance, all from the parameter file. The fifth data line provides two throughput values, the 
first based on the top-of-approach spacing in the upper set of spacing matrices, the second based on the top- 
of-approach spacing in the lower set. In this sample the upper set is providing default, or current FAA, 
spacing since the lateral and vertical motion were disabled using parameter file flags. The next line 
indicates the number of windows used. The size of the spacing file will change as windows are added. 

The rest of the file is divided into an upper and lower set of spacing values. Each set first contains the 
spacing at individual windows, followed by the resulting top-of-approach spacing at the spacing point. The 
spacing at each location is provided in a 3x3 matrix of nautical mile values. While calculations are 
performed using metric units, AVOSS converts to the conventional ATC units of nautical miles for output. 
The columns represent large, B-757, and heavy lead aircraft and the rows represent small, large, and heavy 
following aircraft. Windows 0 through 5 are the default windows with Window 0 at the runway threshold 
and Window 5 at 11.128 km from threshold. Additional windows, 6 through 9 in this case, will be located 
between the other windows. In this case window 6 is at X = 84 meters. Each matrix has a text label to aid 
reading. The text will change according to the flags that disable lateral or vertical motion, hr this case the 
upper set is labeled “Default Spacing” since both wake motion factors are disabled, and the lower set is 
labeled “Trans & Demise Spacing” since all wake motion is enabled. Recall that wake decay is never 
considered in the upper set and is always considered in the lower set. Each label begins either with the 
window number “Win 0” or the word “Approach” to indicate top-of-approach. In this sample the AVOSS- 
produced reduced spacing for large category aircraft following heavy aircraft is 2.75 miles at the threshold 
(Window 0, lower set), 2.50 miles at the other windows, and 2.95 miles at the top-of-approach. Current 
FAA spacing criteria would have applied 5 miles at all windows with 5.47 miles being required at the top- 
of-approach to allow for the speed difference between the slowest heavy aircraft and the fastest large 
aircraft on final. 

#Distance separation arrays (nautical mile) 

#Rows are S,L,H follower. Cols are L,B757,H generator 

#Header : runway, date , time , CorOption,Nsigma, DemiseDef , Nair craft 

#qa_enable, atmpro_good, edata_good, tdata_good, atmpro_f lagl6 

#frac_small, frac_large, frac_757, frac_heavy, round_interval , atc_var 

#tp, dtp 

#NWindows 

R17C 99 12 1 1 0 0 
2 1 90 19 

11110 

0.25 0.6 0.1 0.05 0.5 10 

34.0817 30.5695 

10 

#Win 0 Default Spacing 
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4 .00 


5 . 00 

6 .00 

2.50 


4 . 00 

5 .00 

2.50 


4 . 00 

4 .00 

#Win 

1 

Default Spacing 

3 .00 


5 . 00 

5 .00 

2.50 


4 . 00 

5 .00 

2.50 


4 . 00 

4 .00 

#Win 

2 

Default Spacing 

3 .00 


5 . 00 

5 .00 

2.50 


4 . 00 

5 .00 

2.50 


4 . 00 

4 .00 

#Win 

3 

Default Spacing 

3.00 


5 . 00 

5.00 

2.50 


4 . 00 

5.00 

2.50 


4 . 00 

4 .00 

#Win 

4 

Default Spacing 

3.00 


5 . 00 

5.00 

2.50 


4 . 00 

5 .00 

2.50 


4 . 00 

4 .00 

#Win 

5 

Default Spacing 

3.00 


5 . 00 

5.00 

2 .50 


4 . 00 

5.00 

2 .50 


4 . 00 

4.00 

#Win 

6 

Default Spacing 

3.00 


5 . 00 

5.00 

2 .50 


4 . 00 

5.00 

2 .50 


4 . 00 

4.00 

#Win 

7 

Default Spacing 

3.00 


5 . 00 

5.00 

2 .50 


4 . 00 

5.00 

2 .50 


4 . 00 

4.00 

#Win 

8 

Default Spacing 

3.00 


5 . 00 

5.00 

2.50 


4 . 00 

5.00 

2 .50 


4 . 00 

4.00 

#Win 

9 

Default Spacing 

3.00 


5 . 00 

5 .00 

2 .50 


4 . 00 

5 .00 

2 .50 


4 . 00 

4.00 

#Approach Default Spacing 

4 .11 


5 . 00 

5.28 

3 .76 


4 . 46 

5 .47 

4.50 


5 . 06 

5.06 

#Win 

0 

Trans 

& Demise Spacing 

2.50 


2 .50 

2 . 73 

2.50 


2 .50 

2 . 75 

2.50 


2 .50 

3 . 02 

#Win 

1 

Trans 

& Demise Spacing 

2.50 


2 .50 

2 .50 

2.50 


2 .50 

2 .50 

2.50 


2 .50 

2 .50 

#Win 

2 

Trans 

& Demise Spacing 

2.50 


2 . 50 

2 .50 

2.50 


2 . 50 

2 .50 

2.50 


2 . 50 

2 .50 

#Win 

3 

Trans 

& Demise Spacing 

2.50 


2 . 50 

2 .50 

2 .50 


2 . 50 

2 .50 

2 .50 


2 . 50 

2 .50 

#Win 

4 

Trans 

& Demise Spacing 

2.50 


2 .50 

2 .50 

2.50 


2 .50 

2 .50 

2.50 


2 .50 

2 .50 
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#Win 

5 

Trans 

& Demise 

Spacing 

2.91 


2 .50 

2.50 


2.50 


2 .50 

2.50 


2 .50 


2 .50 

2 .50 


#Win 

6 

Trans 

& Demise 

Spacing 

2.50 


2 . 50 

2 .50 


2.50 


2 . 50 

2 .50 


2.50 


2 . 50 

2 .54 


#Win 

7 

Trans 

& Demise 

Spacing 

2.50 


2 . 50 

2 .50 


2.50 


2 . 50 

2 .50 


2.50 


2 .50 

2.50 


#Win 

8 

Trans 

& Demi se 

Spacing 

2.50 


2 .50 

2.50 


2.50 


2 .50 

2.50 


2.50 


2 .50 

2 .50 


#Win 

9 

Trans 

Sc Demise 

Spacing 

2.50 


2 .50 

2.50 


2.50 


2 .50 

2.50 


2.50 


2 .50 

2.50 


#Approach Trans & Demise Spacing 

2.91 


2 .50 

2 .50 


3 .76 


2 . 95 

2 .95 


4.50 


3 .59 

3 .61 



A log file is produced to summarize the results of multiple runs. The file provides a TECPLOT header to 
allow rapid plotting of a full day of spacing results. The file contains one line of data per 30-minute 
AVOSS cycle, or 48 data lines for a full day of operation. Each line lists date, time, the lower set top-of- 
approach spacing in the order "LS" "BS" "HS" "LL" "BL" "HL" "LH" "BH" "HH" where S, L, B, H are the 
4 categories and the first letter is the leading aircraft category, i.e., LS = large leading a small aircraft. The 
next 9 values are the upper set for the same 9 categories, which normally are the default or FAA spacing. 
Next are 6 fields for meteorological weather observation data (time, visibility, ceiling, wind direction, wind 
speed, and precipitation). A process for merging the log file with hourly weather reports was intended to 
fill in these fields and allow sorting results by weather domain. The merge routine was not written in tune 
for deployments so these fields are filled with "9999”. Next are the status of five parameter file flags, 
DISABLE_LAT_UP, DISABLE_VERT_UP, DISABLE_LAT_LOWER, DISABLE_VERT_LOWER and 
QA_Enable. Next the quality status of the three weather file types is listed (0 fail, 1 pass), and finally the 
individual QA flags of each weather file type. To save space only the defined flags are listed. In total there 
are 61 fields per line. The log file is written by the AVOSS core code and is appended to at each AVOSS 
execution. It is up to the user or shell code to copy the file to another name or location at the date change 
over to force AVOSS to create a new file. The sample below contains the header and one line of data from 
a log file. The length of each line mandates line wrapping in this printed format. 

TITLE= "AVOSS Prediction Log File from: 1999, 12, 1, 0, 0, 0 to 1999, 12, 1, 1, 

3 0, 0 " 

VARIABLES^ "Dt " "Tm" "LS" "BS" "HS" "LL" "BL" "HL" "LH" "BH" "HH" "DLS " "DBS" 
"DHS" "DLL" "DBL" "DHL" " DLH " " DBH " " DHH " "TP" "DTP" "MTm" "Mvis" "MCI" "Mwd" 
"Mws " "Mprec" "PF1" " PF2 " " PF3 " " PF4 " " PF5 " "AGood" "EGood" "TGood" "WQ16" 

"WQ13" "WQ12" "WQ11 " "WQ10" "WQ9 " " WQ8 " "WQ7" "WQ6" "WQ5 " "WQ4 11 "WQ3 " " WQ2 " 

"WQ1 " "EQ16" "EQ7 " "EQ6 " "EQ5 " "EQ4 " "EQ3 " "EQ2 " "EQ1 " "TQ16" " TQ2 " "TQ1" 

ZONE 1=3 F= POINT 

19991201 0000 4.12129 4.3561 5.30665 3.74367 2.92169 2.92169 4.48002 3.57156 
3.57156 4.12129 5.00001 5.30665 3.74367 4.39784 5.39026 4.48002 5.04083 5.04083 
33.5788 31.9784 9999 9999 9999 9999 9999 9999 110011100000 56 60 67 
6 100 61 37 00000000000050 

A statistics file is also produced for each day of operation. The data in the statistics file provides a detailed 
high-level summary of a day’s operation, including the number of system runs, weather system 
performance, spacing statistics, and wake observation comparison statistics. Like the log file, the AVOSS 
creates the statistic file if it does not exist and modifies it with accumulated statistics at each 30-minute 
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cycle if it does exist. It is up to the user or shell code to move or rename the file to reinitialize the statistics. 
Statistics over longer time periods can be accumulated simply by running continuously without removing 
or renaming the file. This file accumulates statistics on AVOSS spacing results as well as on comparisons 
to observed data. File contents are described throughout by “#” comment lines. The file begins with the 
date and tune that it was begun and last updated. In this sample the file was written over a 13 -minute 
period since it was generated by a batch reprocess of archived field data. The next data line indicated the 
total number of runs and the number run with weather files that passed the quality tests. In this sample 24 
of 30 runs were made with wind data that passed the quality tests. The next line provides throughput 
statistics for all runs, including the mean AVOSS value, the mean FAA-criteria value, and the minimum, 
mean, and maximum percentage increase. In this case the mean runway throughput from the 30 runs with 
AVOSS spacing is 33.4, the mean increase was 6.23 percent, and one run produced a 14.34 percent 
increase. The next data line provides the mean spacing value, at the top-of-approach, for the nine category 
pairs. Next the mean spacing reduction, again at the top-of-approach, relative to current criteria is listed. 

In this sample the mean spacing reduction behind the B-757 is over 1 nautical mile for all follower 
categories. The next two lines indicate the mean and the variance of the spacing change for each category 
pair between the half-hourly updates. This is a measure of the stability of AVOSS spacing values for use 
by ATC. 

The next block of statistics relates to the compar ison of predicted and observed wake motion. First data 
echoes TauMin and TauMax from the parameter file, then counts the fields received from each sensor. The 
comparison code will reject wake files for several reasons (see figure 6) and the counts of these occurrences 
are listed. In this list the wake sensor identifications are wind line (wll), NASA pulsed lidar (lna) and 
Lincoln continuous wave lidar (Hi). In this sample a total of 351 wake files were available and only 102 
met all criteria for use. 

Next four- groups of numbers with the same format provide residence time buffer statistics for all sensors 
combined, and then broken out by sensor. The “#” comment lines describe the format. The first line 
provides class 3 (soft) buffers and the counts of class 1 and 2 events. The next line describes class 4 (hard) 
buffers. In this sample, when all sensors are combined, there are 1 1 class 3 buffers (8 positive and 3 
negative), 91 class 1 events, and no class 2 events. The next line in each group gives the mean and 
standard deviation of all soft and hard buffers, then the mean of all exceedances, where an exceedance is a 
negative class 3 or 4 buffer. The exceedance mean is done for all exceedances, then all soft exceedances, 
and then all hard exceedances. The hard exceedance mean of “9999” indicates that no hard exceedances 
were detected and a mean could not be computed. The final line in each group gives the largest soft and 
hard exceedance detected. The data in this group shows 91 class 1 events, 68 of which were detected by 
the pulsed lidar, the average buffer calculated was a positive 34.3 seconds, three exceedances were 
detected, 2 from the pulsed lidar and 1 from the CW lidar, and no hard buffers were calculated. The largest 
soft exceedance was 60 seconds and was provided by pulsed lidar data and the largest exceedance seen by 
the CW lidar was 4 seconds. 

The final group of data provides a distribution of exceedance data into the indicated tune bins. The data in 
this sample shows one soft exceedance each between 0 and 5 seconds in duration from the CW and pulsed 
lidars, and one soft exceedance of between 40 and 80 seconds from the pulsed lidar. 
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# AVOSS Statistics File 

# Start and Stop Date/Time 
000611 153327 

000611 154647 

# Num Runs (total and ATMPRO / EDATA / TD AT A Good) 

30 24 30 21 

# Throughput averages (AVOSS, default, increase min/mean/max) 

33.40 31.44 0.74 6.23 14.34 

# Average spacing values for LS, BS, HS, LL, BL, HL, LH, BH, HH 

3.658 3.910 4.318 3.767 3.046 3.399 4.572 3.693 3.991 

# Average spacing reduction (from default) for the 9 pairs 

0.337 1.090 0.842 0.000 1.338 1.975 0.000 1.331 1.033 

# Mean spacing change between consecutive updates for the 9 pairs 

0.033 0.086 0.086 -0.001 0.037 0.072 0.001 0.015 0.049 

# Variance of the spacing change between consecutive updates for the 9 pairs 

0.380 0.642 0.736 0.092 0.429 1.000 0.083 0.378 0.573 

# 

# Exceedance statistics: 

# Wake compare TauMin & TauMax are: 50 120 

# Bad file counts (Wake Sensor, Spacing & Predicted Tau) : 0 0 0 

# Number of all wake sensor files (lna. Hi, wll, total) 

# Number with no AVOSS prediction (lna, lli, wll, total) 

# Number with invalid tau values (lna, lli, wll, total) 

# Number with invalid X or AC_ID (lna, lli, wll, total) 

# Number of valid wake files (lna, lli, wll, total) 


110 

164 

77 

351 

26 

41 

35 

102 

12 

93 

34 

139 

2 

6 

0 

8 

70 

24 

8 

102 


# 

# Four-line format for Combined and Individual Sensor Statistics: 

# Number of soft buffers (total, positive, negative) & Class 1, Class 2 

# Number of hard buffers (total, positive, negative) 

# Mean and std dev of all buffers (sec) then exceed mean (total, soft, hard) 

# Maximum exceedance time (soft, hard) 

# 

# Combined Sensor Stats 

11 8 3 91 0 

0 0 0 

34.3 40.1 22.3 22.3 9999.0 

60.0 0.0 

# Pulsed Lidar Stats 

2 0 2 68 0 

0 0 0 

-31.5 40.3 31.5 31.5 9999.0 

60.0 0.0 

# CW Lidar Stats 

1 0 1 23 0 

0 0 0 

-4.0 9999.0 4.0 4.0 9999.0 

4.0 0.0 

# Wind Line Stats 

8 8 0 0 0 

0 0 0 

55.5 10.5 9999.0 9999.0 9999.0 

0.0 0.0 

# 

# Exceedance Distribution 

# Time_Bin Soft: lna lli wll Hard: lna lli wll 

0-5 110 000 

5- 10 000 000 

10-20 000 000 

20-40 000 000 

40-80 100 000 

> 80 000 000 

The final output file type discussed is a log of exceedance events. Whenever a negative residence tune 
buffer is computed a summary entry is written to this file. The purpose of the file is to provide an index to 
events that merit additional analysis, or during field operations may merit immediate examination of 
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weather sensor and wake sensor inputs to verify system health. The exceedance log file that corresponds to 
the statistics file above is shown below. Each line provides date, GMT tune, the aircraft identification, the 
location of the prediction window involved, the wake sensor identification, the buffer type (soft or hard) 
and the exceedance duration. This data allows rapid isolation of the particular weather data set, wake 
prediction, and sensor file involved. 


991201, 172320, 
991201, 174811 , 
991201, 232112 , 


DC 8 , 1702, lna, soft, 60 
B737 , 1702, lna, soft, 3 
B777 , 84, Hi, soft, 4 
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Appendix D - Lab Notes 


During the AVOSS development lab notes were kept as a Word document. A slightly condensed version of 
those notes is provided in this appendix as additional insight into the development process and lessons 
learned. The notes are provided in the order recorded, with minor grammatical cleanup and clarification of 
terms. Some material has been omitted that was judged to be insignificant to understanding the system 
evolution or confusing in light of later changes. In some cases this material is more fully explained in the 
text of this report. 

Dec 11, 1996: 

The idea of AVOSS version 1 is to provide an end-to-end AVOSS system that will: 

1. Force data specifications and interfaces of all required systems. 

2. Act as a checklist, or discovery mechanism, to list all the areas of work and tasks required to 
develop and operate an AVOSS. This knowledge will be incorporated in later version design, 
add or re-prioritize research activities, or used in a SOW for a contract effort. 

3. Provide the first data on the most critical factors and domains (for example decay at the 
threshold) required for spacing reductions. 

4. Provide the framework for testing enhanced predictor algorithms and weather systems. 

The mechanism for evaluating the uncertainty in wake behavior due to uncertainties in the weather 
is currently simplistic. A brute force method of calling the predictor algorithm with mean weather, 
mean plus n*sigma, and mean minus n*sigma will be used with no attempt to call with different 
airplane weiqhts or search for the worst case combination of conditions. This is a research area in 
itself. 

A different default separation matrix is needed at the runway threshold than at the outer marker, 
since there are threshold separation requirements for Small following Large and Heavy. In this 
implementation a default separation matrix will be placed in the parameter file. This matrix will be 
the same for all windows except the threshold, or window 1 . The compression algorithms will adjust 
outer marker spacing if required to meet the threshold requirement. 


February 28, 1997: 

After a hiatus from AVOSS design, work resumed the week of Feb 24. Processes worked on 
included the steps and order required to go from wake prediction time history to approach spacing, 
and definitions of the diagnostics required from these calculations to assess system level 
performance. 

Definitions: Window spacing is the distance or time spacing required at any one window to meet 
only the wake constraint at that window. Approach spacing is the distance or time spacing 
required at the “spacing point”, or outer marker in this case, to meet all the spacing constraints 
along the approach. It takes into account the change in spacing of aircraft due to speed 
differences. 

The final output of the AVOSS (approach spacing) will include the distance needed to 
accommodate space compression. Therefore, when producing the “default” spacing matrix the 
output will contain some cells that are larger than the usually seen matrix. This can be partially 
offset by producing an output of the distance-based window spacing at each window. This output 
has not yet been written into the specifications. 
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July 1, 1997: 


AVOSS is being descoped per program funding cuts. The changes will not be reflected in the 
Version 1 to be deployed at DFW this year. The changes include calculation of CATEGORY 
spacing rather than aircraft type spacing, use of demise rather than decay to threshold. Small 
category aircraft will not be given reduced spacing due to demise. We will need to model fewer 
aircraft types, only enough to bound wake behavior in each category. 

August 19, 1997: 

Getting back into AVOSS design after another long gap for project management tasks. Realization 
about current approach to estimating confidence intervals of window spacing: We are only 
evaluating mean and mean +- N*sigma cross winds. It is possible that this will miss the most 
critical crosswind in cases of light cross wind and high sigma. For example, if the crosswind is 4 
m/s with sigma = 3 m/s, and we apply 3 sigma to the calculation, then we will only evaluate wake 
trajectory for -5 m/s, +4, and +1 3 m/s. This could lead to low window spacing intervals although 
zero cross wind is included in the uncertainty interval and could lead to stalled wakes. 

August 22, 1997: 

Implement fix to problem noted above: If the magnitude of (N*Standard Deviation) is greater than the 
mean cross wind, then lateral wake drift will not be used to reduce spacing. Vertical motion and 
decay may still provide reduced spacing in this case. 


August 25, 1997: 

For treatment of variants at DFW, treat the following types as one: 

B737, B73F, B73J, B73S will all be considered as one type within AVOSS. The data file labels 
these as B737. 

MD80, MD83, MD88, MD90 will all be considered as one type. Data files label these as MD80. 


Sept 13, 1997: 

Comments from Donner suggest that the predictor code is using the assumption that wake ascent 
rate is tied to circulation, i.e., sign of circulation can reverse. This must be investigated and 
removed from the system if true. There would be obvious dangers from a system that predicted 
circulation sign reversal when sink rate stops. 

November 4, 1997: 

The following represent a summary of decisions made regarding the AVOSS code rewrite and other 
post-deployment activities: 

1. Go to a flat earth assumption. The ground elevation does not differ significantly at DFW in the 
near runway region, and does not effect wakes at far from runway locations. Simplify the 
parameter file, data volume, and internal logic by removing all references to elevation and using 
the runway Z-axis for all altitude references. This would need to be changed in later versions of 
AVOSS either for hilly terrain or if the airport density altitude needs to be considered. 

2. The safety corridor will be standardized in terms of the distance from the runway where the floor 
drops to the ground. Previously tying the location to the middle marker and outer marker adds 
unnecessary survey issues and variations. The wake behavior and flight technical error also are 
not effected by middle marker position. The "no floor" position will be set at the point where the 
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glide slope reaches 200 feet Z, and the approach spacing will be computed at the X location of 
the glide slope intercept. 

3. Lateral wake motion will not be allowed as a separation reduction mechanism at distances from 
runway larger than the glide slope intercept. This enables the same reduced spacing on the 
localizer prior to glide slope intercept. 

4. The wake predictions and output matrices will not include small aircraft. Small aircraft 
distances will be added as part of the external interface. 

5. Wake coordinate transformations will be moved from AVOSS to the sensors. In future 
deployments the wake files will give wake location in runway axis. This also implies changes to 
the wake file header, to be resolved. 

6. Difficulties in getting real-time TKE and thermal profiles will be corrected in stages. Since 
thermal profiles are not expected to be first-order effects, the AVOSS re-code will make an 
assumption of a standard atmospheric lapse rate (stability TBD). A fixed TKE value or profile 
will also be provided. Currently we do not know the precise turbulent scale length to use as a 
TKE input to the predictor, and Fred expects significant progress on this in the next 6 months. 
His results will be added when available. 

7. Simplify the code and add features in small steps. The first recode will only provide wake 
based separation criteria (no default limit) and will use fixed TKE, thermal profiles. Default min 
and maximum separations will then be added, as will diagnostic calculations. 

8. A window class (C++) will be added. The constructor will compute the corridor dimensions. 

This simplifies the parameter file and enables dynamic window creation. Although a window will 
exist at the glide slope intercept, the point of the glide slope intercept itself will be the reference 
point for adjusting approach times. 

9. Change the parameter file and aircraft data to metric units. Review and clean up unused values. 
November 8, 1997: 

Discussions with Tom Doyle yesterday indicated that DFW, and a few other airports, have glide 
slope intercept altitudes well above the nominal 1600 feet or so AGL. DFW uses 5000 feet MSL 
(about 4400 feet or 1 340 meters AGL) for runway 1 7C when using the triple approaches. This 
implies two things: (1) the weather system and displays need to reach an altitude of close to 1500 
meters and (2) the corridor needs some redefinition. Using the current corridor floor slope will 
produce a large distance between glide slope and the floor at these large distances. We may need 
to allow the floor to drop below the glide slope to some maximum delta, and then maintain this 
offset at larger distances. 

Nov 12, 1997: 

Investigation conducted to determine a method of combining transport and decay times into 
separation arrays, considering the new category-based spacing. Questions were: 

1. Do we need to carry each aircraft type through all the time and distance arrays, or just worst 
case transport (T) or transport and decay (TD) time for each category? 

2. If we go to using min and max speeds of each category, do we need to use both min and max 
or only one? 

Note that simplification from a 20x20 array should be possible, since decay time is no longer a 
function of the follower aircraft type. The investigation determined the following: 

1 . The worst-case aircraft type may be different at each window. If we only used the worst-case 
time for a category, and a different airplane had a worst-case speed, the final calculations would 
be unnecessarily large. The wake T and TD time must be carried for each generator type until 
the final step of determining category -based spacing. 

2. We can simplify the follower axis of the array to category, using only worst case (Vmax) 
category speed for adjusting window times to approach time (assuming that no windows exist 
outside the "Spacing Point" where the approach time is calculated. 

In this method we define a "Spacing Point". All window times are adjusted to this point, and it is 
not absolutely required to have a window at this point. The adjusted times are; 
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T = T 

A SP 1 Win 


+ tt g - tt f 


where subscript SP denotes Spacing Point, T Win is time at a window, TT is Transit Time from the 
Spacing Point to the Window, G denotes the generator aircraft and F the follower aircraft. The 
values of TT are determined by the compression technique in use. For AVOSS 1.1 this is simply 
the distance covered divided by the average speed, or: 


T = T + 

1 SP 1 Win ~ 


(X sr -X r „) (X sr -X w „) 


In the case of a window between the runway and the Spacing Point, the only follower time required 
is the Maximum Speed of all the aircraft in the specific follower category. If we only used one 
generator speed then the minimum category speed would provide the most conservative Spacing 
Point time. 

In the case of a window beyond the spacing point, the most conservative time is provided by the 
maximum generator speed and the minimum follower speed. 

For AVOSS 1.1 windows outside the spacing point do not serve a function and will not be allowed. 
Discussion with FAA & industry is required to determine the need for such windows and the desired 
algorithms for using them. 

Modify existing Approach and aircraft data classes as follows: 

• Change the window XLoc test to disallow any windows at X > X of the spacing point). 

• The "spacing point" will be the glide slope intercept point GSJntX. 

• Add a comment to the Approach code that changing the maximum window X limit also requires 
changes to the compression code and a function to return minimum category speed. Add 
similar comment to compression code that minimum follower speed needed if X is outside 
spacing point. 

• Add a member function to Acdata to return the maximum speed of any category. 


December 8, 1997: 

Current code written includes window and approach classes, a modification to Don’s profile 
generator code to allow linear interpolation of wind at any altitude, a mod to Don’s aircraft data base 
to return the Vmax of any aircraft category, and a WSeps class to compute time and distance 
separations. All these currently run together with real-time DFW data. 

Don and I are working to get the wake predictor code operational. It is currently linked but not being 
called. It seems to run okay when called with the NWRA C driver code, after we removed the 
commas from the input files. I will write a class based on the NWRA code to call the APA 
predictor. By structuring this such that it passes the aircraft and weather data pointers rather than 
discrete arguments, it should be easier to add additional predictor codes at a later time, i.e. have a 
section of code to select the appropriate predictor, then call the appropriate predictor driver shell 
that has access to all weather and aircraft data. Initial circulation strength is currently computed 
from the aircraft data base speed, ignoring the difference between indicated and true airspeed. 

December 15, 1997: 

There is a need for more intelligent residence time calculation. Currently the lateral and vertical 
transport times are kept separate until the last step. This is done in part to diagnose which factor 
(lateral or vertical motion) is most effective in reducing spacing. Several problems can arise: 

1 . A wake may leave the corridor out of one boundary, then leave the other boundary at a later 
time, then reenter the first boundary. An example would be a wake that sinks below the floor in 
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50 seconds, leaves the lateral boundary at 75 seconds, then bounces and reenters the vertical 
limit at 90 seconds. The final residence time produced by the current method would either be 
75 seconds or 9999, even though the wake has been continuously out of the corridor since 50 
seconds. 

2. If a circular or elliptical corridor cross section is devised then the lateral/vertical numbers lose 
their meaning. 

3. Currently the wake predictor track search engine returns 9999 for any Tau whose exit criteria is 
only met in the last data time, or is never met in the file. This can cause unnecessary increase 
in spacing when a predictor is run for 3 weather cases. For example the vertical transport time 
may be valid for two weather conditions but 9999 for the third due to a different wake factor 
causing the track to terminate before the wake sinks below the floor. In this case 9999 would 
be returned at the wake transport time, and is overly conservative. 

Consider replacing the lateral/vertical times with a residence time instead, or add left/right residence 
as two additional values. This may be done in the next version of the AVOSS, but for this version 
the lidar files should have two extra values added, Transport Port and Transport Starboard. This 
would produce a line of 8, rather than 6, variables. 

Times: Horizontal, Vertical, Transport, Demise for port then starboard. 

December 16, 1997: Draft rules for derivation of the various wake residence time parameters, from 
either wake sensor or predictor algorithm. 

General: The times produced will represent the time at which the sensor or predictor data verifies 
that the particular wake characteristic (i.e., demise, lateral motion, vertical motion, or overall 
transport) meets the criteria for safe aircraft passage. The time should not represent the last time 
at which the wake could be sensed or quantified. For example, if demise is defined as an observed 
circulation of 90 meters squared/second, the predictor and sensor demise values will reflect the 
time at which the wake is observed at a strength below 90. Failure to observe the wake at all 
cannot be construed as meeting the demise value. This position may be altered in later versions, if 
adequate sensor or predictor validation demonstrates acceptable probability of detection. When a 
particular wake characteristic cannot be quantified then the returned time should be 9999. 

The wake predictor currently in use provides time histories of wake motion and strength. The 
returned time values for transport or demise represent the latest time at which the predictor places 
the wake position or strength outside the safety region. If the wake track has no data points 
outside the safety region, or only the last point in the file is outside the safety region, then 9999 is 
returned as the time value. At least two points outside the safety region are required. If the wake 
reenters the corridor the first exit will not be returned. The final time value will reflect the last exit 
from the corridor. 

The algorithms used by the predictor code and the wake sensors to determine these times from 
wake tracks will differ primarily in the need to handle noisy data. Predictor algorithms in general will 
provide smooth wake tracks, while sensor data will provide sensor position plus measurement 
variance. 

Demise Time: A value (WLIMIT) of observed circulation that represents wake demise will be 
provided. This value will generally be in the range of 50 to 90 meters squared/second during the 
AVOSS program. The wake predictor will return 9999 for demise time if the prediction run 
terminates prior to two data points being below WLIMIT. If at least two data points are below 
WLIMIT in strength, the first time that the wake is below this strength will be returned. 

The wake sensor data should be processed similarly, except that, for this program, the strength 
data may be smoothed prior to the WLIMIT test, or other sensor specific processes may be 
employed to best estimate when the demise has occurred. In the case where a wake track is lost 
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prior to strength reaching the WLIMIT value, extrapolation may be used provided the following 
conditions are met: 

1 . A quality wake track has been maintained at least X seconds prior to wake loss. 

2. The wake circulation strength was no higher than Y meters squared/second prior to track loss. 

3. The extrapolated demise time is not more than Z seconds after track loss. 

4. Suggested values of X, Y, Z: 15 seconds, 110 m A 2/s, 10 seconds. 

The intent is to provide a demise time value when the sensor data almost tracks the wake to 
demise, but limit the degree of extrapolation allowed. Each sensor team must document the 
method used to filter data and provide demise times for later transfer to FAA, ATA, ALPA groups. 

Lateral Transport Time: A value of Ylim is used to describe the lateral extent, from runway 
centerline, of the safety corridor. This value ranges from about 45 meters at the runway to over 200 
meters near the outer marker. The predictor algorithm will return a lateral transport time of 9999 if 
the wake is still less than Ylim from centerline at the end of the track, or if it exits only at the last 
data point. The wake sensor data should perform similarly. If the wake track persists until the 
wake has left the corridor (at least two data points), return the first time that the wake leaves (and 
stays out of) the corridor. In the presence of noisy data, sensor specific track filtering may be 
employed, or a process whereby at most one point reenters the corridor after exit can be used. The 
process must be documented for description to industry groups. If the track is lost prior to corridor 
exit, return 9999. 

Vertical Transport Time: A value of Zlim is used to define the Z coordinate of the safety corridor 
floor. This value is zero near the runway, preventing separation reduction due to vertical transport. 
The predictor and the wake sensors should process this data in the same manner as the lateral 
transport, that is return 9999 if safety corridor floor exit cannot be shown, and return the time of the 
final corridor exit if that time can be determined. The wake sensors may perform filtering of noisy 
data. 

Transport Time: Due to the ability of wakes to depart and reenter corridor vertical or lateral limits, 
simple processing of lateral and vertical wake motion times may produce overly conservative 
residence time values. An example is a wake that sinks below the floor at 50 seconds, exits the 
lateral wall at 70 seconds, then bounces and reenters the vertical boundary at 75 seconds, while 
still outside the lateral boundary. In this case the vertical transport time would be reported as 9999 
(assuming the wake never sank below the floor a second time) and the lateral time would be 
reported as 70 seconds. Combining the two values would produce a residence time of 70, although 
the corridor was free of the wake at 50 seconds. A test that uses lateral position OR vertical 
position to derive an overall transport time will also be applied. The same rules for returning 9999 in 
the absence of confirmation of corridor exit and treatment of noisy data will be followed. 

January 28, 1998: 

Examination of first runs of AVOSS in early January indicated that the predicted spacing is rarely 
less than today’s standards. This was particularly true for any aircraft following a large generator. 
Likely reasons: 

1 . The Lincoln Profile Generator continues to provide a standard deviation “bloom” at about 50 to 
60 meters. The large standard deviation combined with low cross wind will disable the use of 
wake lateral transport. This is likely a major cause since windows 0 and 1 frequently showed 
very small required spacing (less than 1 mile) while window 2 usually showed a much large 
requirement. Window 2 is at x=843 meters which gives a glide slope height of 60 meters, 
which is the altitude of the standard deviation bloom. Lincoln sent an email on 1/27/98 saying 
that a bug in the PG code was just corrected and should fix the bloom. We have not had time 
to evaluate the change. 
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2. The large category contains the ATR-72. The wake from this aircraft will have a small sink rate 
compared to the other large aircraft. This raises the question as to whether this aircraft should 
be a constraining factor for the small commuters. 

3. The wake predictor code is not yet highly validated or accurate in ground effect. Not all factors 
are modeled yet (shears, formation of wakes in ground effect..). 

4. The files examined were produced by early code that does not read the parameter file. There is 
a little uncertainty as to whether we were running corridor option 1 or 2. The output file headers 
say 1 but 2 was intended. 

February 19, 1998: 

Performed examination and verification (by hand calculation) of system outputs using the profile 
atmpro_17C. 98021 3_1 34255. Verification consisted of taking the raw wake track outputs, manually 
determining transport and decay times at each window for each aircraft, manually computing 
window spacing and approach spacing using the aircraft data base and profile headwinds. All 
checked values were correct (spot check of spacing matrix elements, including all followers behind 
B757 and heavy for Transport & Demise and all followers behind large and 757 for transport. 

Observations: 

1 . The Fortran APA routine did not compute a wake track at all for the AT72, leading to 9999 tau 
values for the large generator. Wakes generated low always seemed to level at exactly 15.00 
meters altitude with no bounce or oscillation. Why? 

2. While the B747 had the worst case wake demise time, when adjusted back to the spacing 
point the EA34 created the worst case approach spacing. The difference in time was about 16 
seconds, or about 0.6 miles. The difference was due to the lower assumed approach speed of 
the EA34 and the fact that the limiting window was near the runway. More space is then 
required behind this airplane at the spacing point. This implies we cannot simply model the 
demise of the worst case generator in the AVOSS system, as previously assumed. The 
interplay of wake behavior and aircraft operations procedures may create a different worst-case 
airplane. 

3. The sign of the cross wind changes with altitude in this profile. This implies the possibility of 
predicting low transport times at several windows, and not catching a large transport time at a 
location (altitude) between the windows where the wind is lighter. Potential solution: Only use 
vertical wake sinking above some minimal altitude such as 1 50 to 200 meters, and either use a 
dense window structure or create a special window if a low cross wind condition is detected. 

4. Wake sink time was always less than 50 seconds in this case (at windows where sink was 
possible). Does this also argue for simplifying the system to only using wake sink and demise 
(not lateral motion) above some low altitude, with a safety system to detect conditions that will 
arrest the sink rate? 

5. Window 2 (843 meters) always failed to provide reduced spacing in this run. The cross wind 
was only 0.5 m/s, variance was 0.46, and there is no corridor floor. 

The predictive algorithms are not yet sophisticated enough to detect situations that will prevent 
normal wake sinking. 

March 24, 1998: Development in moving the residence time calculation function to the sensors: 

RTI found that in some cases the wakes are generated outside the safety corridor in VMC 
conditions. The logic they will implement is that if a wake pair is generated outside and drifts in - 
apply normal rules to exit time. If the wakes never enter the corridor, use 9999 for the time. This 
raises the issue of revalidating prior aircraft localizer tracking statistics in IMC conditions, and 
perhaps verifying the safety corridor size in VMC to reflect the larger dispersion. 

March 25, 1998: Dave Burnham advised that additional fields may be required at the end of each 
residence time line in the wind line wake files. In some cases the wind line may not detect wakes 
until AFTER they have left the corridor lateral limits, due to the requirement that wakes settle into 
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the proximity of the array before they are detected. If they simply report the first time the wakes are 
detected outside the array, they may greatly over estimate wake residence time. 

April 17, 1998: We are working the issue of introducing the “most appropriate” turbulence data into 
the APA predictor algorithm for real-time AVOSS, to be used until more is learned about turbulence. 
Lessons: 

• The APA predictor turbulence input “q” should be Sqrt(2*TKE). NWRA uses the 1-minute TKE 
average at the tower top. 

• NWRA has altered gain 3 in the Greene equation to be 0.41 , rather than the original 0.8199. 
They say it provides better correlation to data. Fred/Sarpkaya are unsure. 

• Don Bagwell is creating code to take the tower top TKE and load the QDATA file with q. The 
issue is - grab the last one minute TKE, create a running average of the last 15 1-minute 
averages, or other? 

None of these is actually implemented at this time in the real-time code. 

April 17, 1998: 

The lidar wake files received from RTI do not fully comply with the file specifications. These 
problems were discovered by Metin: 

1 . The scan plane X values given in the files do not correspond to AVOSS-defined windows. The 
explanation from RTI is that they had to tweak the scan azimuth to avoid poles, trees, etc. 

Why was this not communicated to AVOSS while in the field in September and how do we 
prevent future misunderstandings? 

2. More than one wake track in a given file at times. 

3. Beacon times provided by RTI do not agree with beacon times provided by Lincoln for a given 
window. Metin will use Lincoln times. 

April 24, 1998: 

More discussion with Lincoln/RTI/Metin: The event correlation process only tags files with aircraft 
type if the estimated passage time is within 30 seconds of the ATC radar beacon time. This was 
first discovered with the Volpe wind line when it was brought back on line and Lincoln was not 
tagging the files with aircraft type. For deployment we need: 

1. Positive assurance of coordinated clocks, at all sensors and ITWS network, wake network and 
CTAS network. 

2. Automated process to open files and notify us if aircraft tagging is not taking place. 

3. Investigate more positive means of determining aircraft passage time at the sensors. 

Note: The event correlation process uses ATC radar beacon data to determine aircraft passage 
time at each wake sensor scan plane. The sensor provides an estimated aircraft passage time 
which may be in error, i.e., the sensor may not detect the aircraft until the wake is first detected 10 
or more seconds after passage. The event correlation process examines the sensor-estimated 
passage time and the ATC data derived time and then corrects the wake file residence time values 
and wake time history data time tags. 

May 3, 98: 

Two issues have surfaced that will need attention in the system validation or test-bed phase: 

1 . Currently the system will not allow lateral wake drift to reduce spacing if the cross wind 

standard deviation exceeds the mean. Donner pointed out that it might be possible for lateral 
drift to be used if the standard deviation is set to zero (for example in parametric runs with 
canned data) and the cross wind is very low or zero. This is not an issue in real-time 
operations with the current system, as the standard deviation is always substantial. In the test- 
bed there may be another test required, to prevent spacing reduction if the port/starboard wakes 
are predicted to go out opposite sides of the corridor. In parametric tests, we need to make 
sure that some small standard deviation is included. 
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2. The NWRA predictor uses the (false) assumption that any wake that has stopped sinking has 
also gone to zero circulation. Sarpkaya pointed out the danger of this assumption. NWRA 
replied that they intentionally make use of this assumption since, in their words, wakes are not 
observed to last long once the sink rate is arrested. This comes into the predictor via the 
stratification term. This assumption must be revisited in the test-bed, and proper predictions 
taken to maintain safety. 

May 26, 1998: 

The APA code has recently been revised per instructions from NWRA to improve stability and 
switching from one phase to another. 

A quick sensitivity study to the Demise Definition was conducted today, using the canned QDATA 
then q = 0.50, 0.90, and 1 .20 at all altitudes. These values were estimated from TKE plots from 
Memphis (q = sqrt(2*TKE)). Night smooth air provides TKE about 0.10 and the highest "eyeball 
average" in the day is about 0.7. This provides the q limits of 0.5 and 1 .2. At any one q value, the 
sensitivity of separation to demise values was less than expected (to be quantified later). One 
problem resurfaced: The NWRA APA code seems to be terminating prematurely due to sink rate 
approaching zero, with circulation still high. For a B747 with q = 1 .2 the wake track stopped at 61 
seconds with circulation = 187 and altitude stalled at 26 meters. 

A very interesting observation was seen at q = 1 .2. In this case the following distance of a large or 
heavy, behind a B-757, was less than the following distance behind a Large. This turned out to be 
due to wake sink rate. The B-757 produced a wake that sank below the corridor floor quickly, 
before the demise value was reached. At 70 to 80 m A 2/s the distances behind the B757 and large 
were similar. At larger values of demise the separation for large generators was less than the B757. 
At low demise values much more distance had to be allowed for large generators than for B757 
generators. 

Approximate sensitivity of separation distance to demise value, using demise interval 50 to 90: 

At q = 0.50 slope is 0.14 to 0.18 nm per 10 m A 2/sec of circulation. 

At q = 0.90 slope is 0.08 to 0.18 nm per 10. The 0.18 was heavy behind large. If we only include 
the classes that matter, the slopes were about 0.09 nm per 10. 

At q = 1 .2 slope is significant for large generators, about 0.24 nm per 10 m A 2/sec. For B757 
generators it is very low, about 0.07 nm per 10. Cannot assess slope for heavy generators due to 
premature APA termination, before demise. 

June 11, 1998: 

Tests a few weeks ago showed that the predictor was terminating too early (60 seconds) for some 
aircraft in ground effect. NWRA provided constant changes to prevent phase termination (moved 
from a 60 second limit to a 120 second limit) and this was implemented by CSC. CSC delivered 
yesterday AVOSS Version 1.6, which includes spacing limited to minimum threshold and maximum 
values. 

In preparation for AVOSS sensitivity runs, and to document the potential temperature feature Vs 
sensible temperature, the following was provided by NWRA: 

“The algorithm accepts both sensible (in deg C) and potential temperature (in deg K). If the first 
line of the TDATA file is > 0, then sensible in assumed; if the first line is < 0, then potential is 
assumed. Note that the first line is a single number, NDATA, which gives the number of following 
points in the profile. In the case NDA TA < 0, the algorithm reverses the sign and goes into the 
potential temperature mode. ” 
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12/9/98: Case study 1 (see zip file). While trying to duplicate a JFK3 run locally (weather file for 
981 021_1 64808) on the PC, I found a case where the results were identical to the field data, except 
for the small following large. The field data produced 2.91 nm while AVOSS produced 4.31 nm with 
default windows, and 2.91 nm with the extra window added at 642 meters. The input files and EXE 
file were zipped into Labbook_Case1 .zip. I am using version 1 .62 with the new flags (disable 
vertical or lateral) off. 

12/14/98: Found two bugs. One in WSEPS will cause a "9999" window residence time to be 
overwritten with a lower value, only if a window has been added after the default set, and at least 
one default window produces 9999, and the added window has a lower time. This error occurs in 
the code that finds the maximum of all window adjusted residence times for the approach. This bug 
does not effect any of the DFW data as we have only used the default windows there to this date. 

A second bug is in the spacing limiting code. It computes limit approach spacing from the min and 
max window spacing at each window, then uses these approach limits to limit the computed 
approach time spacing. In the case of reduced spacing at windows near the runway but large 
spacing at some other window, this calculation tends to use FAA default spacing (i.e., 4 nm) rather 
than the actual required threshold spacing (i.e., 2.5 nm) and produces larger approach spacing than 
it should. This makes the AVOSS performance to date conservative, as the error will always 
produce an approach spacing that is equal to or larger than needed. Software request 9A corrects 
this error and delivers code version 1 .7. 

December 20, 1998: 

Another numeric issue with APA: I found a situation where I could find no cross wind value that 
produced a spacing for small followers other than 2.5 or 4 at window 0. At one point changing the 
cross wind by 0.1 m/s caused the spacing to jump between lower and upper limit. Examination of 
residence time outputs and wake tracks showed that the wakes of some large aircraft were 
decaying to zero at almost the exact same time of leaving the corridor. Since the APA algorithm 
stops when the circulation gets to zero, a very tiny change in inputs caused the wake predictor to 
either clear the corridor in about 54 seconds, and give 2.5 nm, or decay while still in the corridor, 
and give 4.0 nm. For production we need a predictor that can carry the motion out farther in time, 
regardless of strength, or we need to get away from explicit equations of motion such as this and 
predict drift or other factors separately as far as possible. Can NWRA modify the code such that 
lateral drift of the wake is modeled out to at least 90 seconds, even if the circulation goes to zero? 

December 23, 1998: 

Potential third corridor option: Rationale - shape the floor such that the transition point (Xt), where 
the floor steps from Z = 0 to Z = K, is such that the initial floor height completely removes ground 
effects on the wake drift, sink, and decay rates. This offers the potential to apply simpler predictors 
beyond Xt, or to apply default behavior with subsystems that look for exceptions (shears, strong 
inversions, etc ). Per discussion with Fred, a conservative altitude, above which ground effect is a 
non-issue, is 1 .5 or 2*span. The largest span is 65 meters for a B747-400. Determine the Xt and 
floor height and clearance (FP_Z - Zlim) for the following conditions: 

1 . The floor is at the bottom of the glide slope limits for a typical 1 .4 degree wide, 3 degree glide 
slope that intersects the runway at X = -305 meters (0.7 degrees below glide slope) 

2. K values (floor height at Xt) of 65m, 100m, 130m (1, 1.5, and 2 * span) 

Set K = (Xt + 305)tan(2.3 degrees). Then FP_Z is (Xt + 305)tan(3) 


K 

Xt. meters 

Xt. nm 

FP Z 

FP Z - K 

Ylim* i 

65 

1313 

0.7 

85 

20 

51.7 

100 

2185 

1.2 

130 

30 

62.8 

130 

2932 

1.6 

170 

40 

72.2 
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Note that Ylim is based on the current corridor lateral shape, which is defined with Xt = 843. A new 
floor or definition of Xt may require revisit of the point where the lateral corridor begins to widen. 

Each of these options provides wake clearance at Xt if the following aircraft is full-scale low on the 
glide slope and the wake is below the floor, but only with the core of the wake. Some influence may 
still be felt. Given that typical sink rates are 1 to 1.5 m/s and runway occupancy time is about 50, 
a larger initial floor height is appropriate to allow for lead aircraft flight technical error and provide a 
greater buffer with the wake , without sacrificing performance. Therefore a suggested initial floor 
shape is to set K = 130 meters. The tradeoff is that the lateral limits are getting wider, and vertical 
motion is being ignored inside the Xt point. This may create a bottleneck in the altitude region of 
about 60 to 130 meters, where vertical motion is ignored, decay is not being sped up by ground 
effects, and drift is less effective due to wide lateral limits. This argues to select K of 65 to 100 
meters. 

1 . Consider a floor definition that provide the following inputs: 

2. Glide slope intercept on runway and angular limits. 

3. K 

4. Minimum value of (FP_Z - Zlim). 

5. Altitude of initial glide slope intercept. 

6. Floor distance below FP_Z at glide slope intercept. 

The algorithm then computes Xt, and Zlim at any X location. 

January 8, 1999: 

Will need more thought on corridor reshape noted above due to: 

1. Fred Proctor's AIAA paper suggesting ground effects may extend up to 3 spans 

2. Realization that ignoring sink up to high altitude will create a wide corridor at that point, 
requiring substantial cross wind. In other words this could create a region on the approach 
where ground effects are not expediting decay, where wake sink is ignored, and a substantial 
cross wind is required due to a wide corridor. 

3. Current project reassessment leading to the conclusion that this type of optimization may need 
to wait for the follow-on due to limited resources. 

Version 1.7 was delivered today and checks against hand calculations. 

2/17/99: Reviewing predict.cpp code for NWRA and revisited the test to skip rerun of APA (runs 
with mean plus & minus N*Standard Deviation wind). One condition for skipping is that the 
horizontal transport time of both wakes is greater than the vertical times for those wakes. The 
premise is that, since the rerun will not change the vertical time with this predictor algorithm, and 
can only increase the horizontal time, there is no need to rerun. This test must be removed if a 
predictor is implemented that varies the wake sink rates between the different weather conditions, 
i.e., shear terms. 

2/18/99: Steve Riddick has found that there is a positive spike in throughput as cross wind is varied 
and TKE = 0 in his batch sensitivity runs. The spike used to occur at zero cross wind, due to 
wakes drifting out both sides of the corridor, and the fact that the batch runs can use identically 
zero mean and standard deviation. I modified his batch code to ignore wake drift if cross wind 
magnitude is less than 1 m/s. Now he sees the spike at 4 m/s cross wind if standard deviation is 4 
m/s, and at 2 m/s if standard deviation is at 2 m/s. Throughput increase is zero as the wind 
increases to the value causing the spike, the throughput increase then jumps to about 6% when 
mean = standard deviation, then drops again to a low value (cannot see that point on the contour 
plot) for about 1 wind mean value, then increases rapidly to > 10%. 

Tentative diagnosis: The test that determines if lateral drift should be disabled consists of 
multiplying the mean by the (mean + standard deviation) and testing for the product < 0. The test is 
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repeated for mean*(mean-standard deviation). If either test is true then lateral drift is disabled. In 
this case the mean and the standard deviation can be identical, therefore the product equals zero 
(fails < 0 test) and lateral drift is enabled. At this wind condition, all three crosswind values run 
through APA produce significant wake drift, either due to strong wind or due to zero wind. In other 
words, the uncertainty technique being used fails to find the worst case drift in this situation. 

To verify diagnosis: 

1. Run these cases with the unmodified version 1.7 software. The results should be the same at 
these wind/standard deviation values. 

2. Examine the residence time output files at the wind value causing the peak and the first wind 
value each side of the peak. At the peak wind value the low-altitude horizontal residence times 
should be low (on order of 60 seconds) while at the wind values each side of peak the same 
values should be high (greater than 80 seconds or 9999). 

3. The best test would be to find the aircraft exhibiting the characteristic in (2) and then examine 
the wake trajectory files. At the wind value causing the peak throughput the wake should be 
observed drifting out opposite corridor walls. 

April 8, 1999: 

Software upgrades will be requested to fix several small issues: 

• Fix the wind mean/standard deviation test noted above. 

• Use the absolute value of the line count in TDATA files, since the nowcast uses negative values 
to signify potential temperature. 

• Repair APA to use temperature in Kelvin 

• Remove old lines from predict.hpp (// #define for nzmax and ntmmax) 

• Correct Asearch bug, change array index from 6 to 8 for reset of 9999 values. 

April 13, 1999: 

NOTICED: that the computed demise time of the right wake is sometimes equal to the last time in 
the wake track file, even when that strength is above the demise definition!!! 

Found bug, when the Asearch function in Predict.cpp was modified to include a separate demise 
value for validation, an array index to rest Tau array values to 9999 was not changed from 6 to 8. 
Therefore the last two values (right demise and demise validation) was set to the last time in the file 
as long as the number of points (ntm) was above the threshold for doing the residence time search. 
Added to list of changes above. 

4/14/1999: 

Also found that the Asearch logic will return 9999 for a time value if the demise or residence 
threshold is already satisfied in the initial condition. This only surfaces for the validation demise 
definition for the ATR-72. The initial strength is about 121 and the validation threshold was set to 
150, the validation time produced is 9999 while the actual demise is at a less time. 

4/21/1999: 

An AVOSS design meeting was held with the NASA lidar team on 4/21/99. An update meeting was 
held on May 3. 

Decisions: 

1 . We will keep the nowcast weather system and the observed weather system isolated from each 
other in this build. No link from nowcast to thermal profile. 

2. We will not send ATC beacon data to the NASA lidar 

3. We will not pursue new hardware for the lidar, i.e., laser range finders to detect aircraft 
passage. 
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4 . 


There will be no 3rd corridor option during the TAP program. Therefore the third line of 
residence time values in the wake data file may be used for other data. These values must be 
integer. 

5. Two methods of computing demise time will be implemented. Method one is the current 

process of providing the elapsed time at which the wake was observed below the demise value. 
Method two provides a single demise time for both wakes, and is defined as the elapsed time at 
which the corridor does not contain any wake above the background ambient turbulence level. 
The threshold for ambient turbulence and the demise value will be provided on the third 
residence time line in the wake files. 

The following items are potential add-ins to the wake file, all could go on the 3rd residence time line 
(as integers): 

1 . A value to indicate if the sensor-provided pass_time1 is accurate enough that the event 
correlation process should not be used to adjust aircraft passage time in the file. 

2. One or two values to indicate the sensor detection threshold, and whether the threshold is 
driven by ambient turbulence or lidar performance (i.e. , lack of signal return) 

3. A word to indicate that the wakes of more than one aircraft are in the corridor at the same time 
and cannot be separated. 

4. A quality word to indicate that the data is considered poor or unreliable for some reason 
(suggest using zero for good data, and non-zero for bad. This lets us define different values to 
indicate the reason, i.e., error numbers. 

5. Demise time defined by absence of detectable wake in the corridor, as defined by the threshold 
provided by item 2. 

Thoughts on variable demise value: 

1 . Requires QA or probability of detection values to ensure that the wake really is not there when 
it’s not observed. 

2. In very calm air the threshold could go down near 50. Is this over-conservative? Would we want 
to make it equal to ambient turbulence with a floor of about 70 to 90? 

3. Does AVOSS need to know the value? AVOSS could make the demise value dependent on 
wind or EDR. We could also keep 90, knowing that strong winds will cause rapid decay and 
reduce the sensitivity to the demise value, while low turbulence will cause such a long lasting 
wake that the value does not matter. The latter assumption may not be true in all 
environments, that is, AVOSS may produce a decay to 90 that reduces spacing, while the 
wake may be observable to 70 for a longer period. 

4. As part of the quality assurance, can the lidar continuously, between tracks, provide automatic 
gain control and verify detection as the threshold is lowered? 

4/22/99: Draft QA information for real-time system: 

This is a set of draft suggestions for the QA status content to be provided in the next AVOSS 
version. The ground rules for a status bit are: 

1 . The information relates to the quality or confidence of the wake predictions and spacing 
predictions provided by AVOSS. 

2. The information is readily determined by each subsystem (wind, thermal, turbulence). 

The format for packing QA status and placing it in the data files is TBD. This is a draft for the 
information content only. Please look this over and let me know if it makes sense from your 
subsystem perspective. Should any items be removed, added, or modified? (NOTE: remainder of 
email message with proposed flag definitions is removed. See current I CD for implemented flag 
definitions.) 

4/28/99: 

Steve Riddick proposed the following cross wind lockout logic for preventing wake drift use in light 
cross wind: 
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To detect occurrence of the region mean-standard deviation to mean+standard deviation overlapping 
the region -min to +min (i.e. where min is a minimum allowable cross wind such as 1 m/s), use: 

((mean - standard deviation) <= min) AND ((mean+standard deviation) >= -min)) 

If the result is true then set Sigtest = 1 

This works. Question: Is lock out of the wake drift when the (mean - standard deviation) is below 1 
too restrictive, when the uncertainty include sensor noise as well as the actual wind standard 
deviation? Example: cross wind mean 4 m/s with 3 m/s uncertainty? 

Decision: Flag this as a safety issue to be addressed in the AVOSS follow-on with industry input. 
For now, assume that the lateral drift is disabled if Steve’s test is true, but use a value of min closer 
to zero. The value will be defined in the code as a variable and changeable at compile time. The 
initial setting of this value will be 0.5 m/s. (Note: The cross wind lockout threshold was set to 1 .0 
m/s). 

Rationale, Notes on EDATA Formats 

Note from 5/24/99: A discussion was held between Dave Hinton and Tim Dasey on 5/24/99 
regarding the tower flux file and EDR data. Summary: 

1. The current Lincoln AWAS process determines wind standard deviation using a 30-minute 
standard deviation of 1-minute wind means. The current fluxpac process uses a 30-minute 
variance of the 10 Hz data to compute TKE. The latter is believed to be anywhere from 0 to 
50% larger than the AWAS process, with little difference on sunny summer days and large 
differences in mechanically generated turbulence on stratiform cloud days. Lincoln may look at 
some data to determine the magnitude of the differences. 

2. The AVOSS has no real need for 5 or 15 minute averages or variances, nor for 5-minute file 
updates. The 15-minute average is a hold-over from the first average period used and the 5- 
minute update a hold-over from the fact that the AWAS has been processed at that interval. 
Reconsider, for AVOSS, only seeing the 30-minute updates with only 30-minute period values. 
Include both versions of TKE in this file, standard deviation from 30 1-minute wind values and 
TKE from 30 minutes of 10 Hz data. 

3. The scientific data format can remain as-is or changed to add new variables. This data can 
continue to arrive at 1-minute updates while 30 minutes are provided to AVOSS. 

4. The 3 and 10 meter savpac data is also needed within AVOSS at 30 minute updates to support 
EDR profile data. The NCSU/NWRA EDR profile code will run within AVOSS. 

5. I need to check with Don or Sarpkaya/Proctor to resolve: 

(a) Should we remove the start time and stop time fields from the fluxpac files, since they 
are not really used, or keep them to prevent changes to file readers? 

(b) If Sarpkaya and/or NWRA derive a relationship between EDR and TKE that affects 
wake sink motion, which wind standard deviation do they need (30-minute average of 1- 
minute winds or true TKE based on 10 Hz data)? 

6. The current Lincoln system timing is such that the AWAS and other files (flux, savpac) will 
generally become available on the hour and half-hour, plus a few seconds for processing and 
writing, say at 30:30 past the hour. 
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Notes on 5/25/99: 

1. Sarpkaya replied and suggested that he would like to see a 30-minute course TKE calculated 
from an average of 6, 5-minute TKE values. He would compare that to a 30-minute EDR. 

2. Consideration: Plotting of sensor data Vs AWAS profiles may require getting the 5-minute or 1- 
minute tower wind data every 5 or 1 minute. The AWAS file however, is only required every 30 
minutes. 

Notes on 5/26/99: 

Sarpkaya indicted interest in TKE_fine only and Mike Kaplan (nowcast) can provide TKE_course 
only. We will drop the TKE_course from the flux file. It can be synthesized later from the AWAS 
profile, since the U and V variance will be contained there. I also decided to split the two competing 
time average data into two file versions of flux and savpac, one at 5 and one at 30 minutes, and have 
them written to two different folders. Tim and Don concurred. 

The U, V, W wind components that are provided at 5-minute periods are used for display and 
comparison of sensor data with AWAS profiles. The data provided at 30-minute periods are used in 
AVOSS wake predictions. Only the updates on the hour and half-hour are used for wake 
predictions. 

— End EDATA format notes 


6/8/99: 

Notes for future enhancements: 

Al Zak suggested using rain data to determine how to treat the radar profiler RASS data. He is 
seeing thermal biases due to rain and can select a different RASS set in these conditions to get 
better thermal profiles. Resources do not allow this level of maturity for the demo system, but 
detailed consideration of all sensor QA issues needs to be revisited for follow on deployments. For 
this demo we will understand that rain, thunderstorms, etc may contaminate sensors. 

6/15/99: Note for future enhancements to software: 

Currently the disable of drift or sink or demise for spacing reductions is applied at all altitudes. This 
should be made an altitude-dependent feature, perhaps by making it a property of each window. 
Parameter file flags could alter all windows, or weather QA and other considerations within the code 
could set individual windows. In other words: make weather QA a function of altitude and make 
ability to disable lateral, vertical, or demise a function of altitude. 

Rewrite the WSEPS function to pass disable flags to it, rather than altering residence time values 
prior to WSEPS. This would allow more modular programming. Once the residence time array is 
calculated then WSEPS could be called as many times are required to get full-feature spacing, 
default spacing, or selectively disable wake factors. In this case WSEPS should probably pass a 
single spacing matrix back to the program, and write a spacing file for each call with both window 
and approach spacing values. 

BETTER YET : Currently the ability to disable one wake factor by resetting the appropriate Tau 
value to 9999 is distributed between predict.cpp and wseps.cpp. Strip these functions out of those 
modules and write a "policy.cpp" module that sits between predict and wseps. After this change 
the predict module would ONLY provide residence time based on wake motion and corridor 
geometry, the policy module would examine those arrays and any weather QA data to reset or 
condition times, and wseps would use these to compute spacing. It may still be necessary to pass 
a category specific demise definition or disable demise to allow the small aircraft special case. 

Also, the "wide" window at the top of the approach would be a "policy" implementation and the 
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windows themselves would not get wider there. These changes will NOT be made for the 
demonstration Version 2 due to time and resources available. We will live with the current 
distributed logic. 

8/23/99: 

AVOSS VI .7 uses disable_vert and lateral flags in predict.cpp to condition the residence time 
arrays, while demise lock out for small aircraft is hardwired in wseps. This VI. 7 technique means 
that Pred_Tau contains times based on lockout of wake factors (actual wake motion time is lost). 
This is acceptable but implies that if sensor observed times are compared, and if motion is disabled 
in the prediction, then the prediction error (buffer) statistics will be biased. This is not a major factor 
in 2000 since the demo will use all wake factors, and batch studies do not have the real-time 
sensors data to compare to. For enhanced flexibility in the future, suggest removing disable’s from 
predict and placing in Wseps. 

October 7, 1999: 

Noticed another challenge in automated comparisons of predicted and observed residence time, due 
to process of taking the maximum of left or right wake as the pair residence time. Assume 

Left Right wake 

predicted lateral times are: 50 sec 9999 sec 

and observed are: 9999 90 sec 

Both agree - the left wake drifts rapidly and the right wake hangs around. If a comparison process 
were to compare the 50 sec prediction with the 90 second observation though, we would 
inadvertently get an exceedance of 40 seconds. 

Also, the wind line will set residence time = first observed wake time, if the wake is first observed 
outside the corridor. This may commonly happen when the wakes are rapidly drifting and do not 
sink to the wind line until they are clear of the corridor. The actual residence time in this case will 
be less than the reported time, but this will create havoc with automated wake prediction scoring by 
detecting exceedance where none exist. In this case the sensor can verify that the corridor is clear, 
but not when the exit happened. (Note: this was later corrected in the wind line logic by reporting 
9999 drift times if the wake is first observed outside the corridor.) 

10/14/1999 
Current issues: 

(1) wake residence time. Comparing wake residence time is proving to be a coordination challenge. 
Different techniques are needed depending on the application (scientific validation of both wakes, 
just prove that the corridor is free, validate the worst-case wake). Different and novel techniques are 
in use by the different teams. One will set residence time to the first time observed, if the wake is 
already outside the corridor when observed, while another will write 9999 due to undeterministic 
clearance time. Another will fit a track to the date and backwards extrapolate to get the clearance 
time. The issue of estimating the residence time of the worst-case (critical) wake Vs both wakes 
has not been addressed. An issue with providing residence times based on first detection outside 
the corridor is that the actual residence time may be close to that predicted, and be much less than 
the time of first detection. The result when returned to AVOSS is an erroneous “exceedance” 
detection. Possible system solutions: 

1 . Go back to passing wake tracks to the main system and then use consistent algorithms to 
curve fit, adjust times, etc. to get residence time. Disadvantage: We only pass a small 
subset of the data available at the sensor (confidence, signal to noise, etc. are not passed) 
and the sensor team is better suited to use all available data for a best estimate. 
Advantage: Common processes at the AVOSS. This will not be done in this program. 
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2. Require that any wake detected outside the corridor receive residence times of 9999, to 
prevent false exceedance detections. Allow very minimal extrapolation for data to the 
corridor. 

3. The current method of comparing wake residence times will discard a wake file if both wake 
times are 9999, even though the prediction might be for default spacing and the 9999 may 
be due to wakes still alive after several minutes. Provide for a residence time value to 
indicate that the wake was definitely still alive inside the corridor at a time equivalent to 
default spacing. Do not use 9999 for both bad value and long residence time. 

The entire concept of matching wake data to predictions (aircraft type, port VS starboard wake, 
tracks Vs residence time) needs fresh evaluation. Also, the use of "9999" to indicate that the wake 
has not left the corridor creates validation problems. The use of this value both for "bad data" and 
for "no corridor exit" prohibits meaningful validation when the wake is predicted to remain in the 
corridor and the wake sensor agrees. 

(2) Nowcast sensitivity: Cases are seen where the difference in spacing for an aircraft pair may be 
over 1 mile (TAPPS Vs observed weather). This situation occurred today when the observed 
weather provided minimal spacing reduction and TAPPS provided large reductions. Observed cross 
winds were less than 1 m/s below 100 m while TAPPS winds were about 2 m/s. Standard 
deviations were about 0.10 to 0.23 m/s in this region. This cross wind is in a range shown by Steve 
Riddick to be very sensitive to small cross wind changes. An effort will be made to better quantify 
the accuracy of TAPPS. We may need to add another term to its standard deviation value to 
indicate this uncertainty. 

(3) Aircraft data base & beacon process: The AC_ID fields being received from ATC are now more 
varied than in 1997, for example getting A310 rather than EA31 and seeing variants of the B727 
(B722, B72Q, etc.) We will create a process (implemented by Lincoln) to match the variants up 
with aircraft data base entries so that more wake comparisons can be made. Some slight errors 
may be expected due to conducting prediction and validation with slightly different airframes. 

Lincoln has learned that the CTAS beacon tracks cut off at about 400 feet AGL. They will need to 
extrapolate tracks below this altitude to estimate passage time. I estimate a 3 second error at the 
threshold if an aircraft made a 10 knot speed change immediately after the radar track was lost. 

11/03/99: 

Need to consider setting up AVOSS for runway 35C operations. (Note: This change was never 
made.) To do this we need: 

1. Change the runway ID in the parameter file from R17C to R35C. 

2. DIST files have runway number in file name, automatically taken from pfile.prm string. The call 
to Compare must still pass the correct file name, DIST_R35C.date_time. 

3. Use that string to select the directory and file name for reading AWAS weather (TDATA and 
EDATA are scalars and require no changes). 

4. Coordinate with Lincoln so that the beacon process runs for R35C. This means that the wake 
sensors on 17C do not get processed. Archive for later transmission to NASA, but do not place 
those files in the area for reading wake sensor data. 

5. The sign of cross wind and head wind must be changed in the TAPPS files in use. AVOSS 
must either (a) read those files and write an altered version for reading or (b) modify the file 
reader to invert the sign if runway ID = 35C. 

6. Display code that resolved sensor data into runway axis must change the runway orientation 
(sodar, profiler, tower), cross wind = wind speed * sin((runway heading - wind 
direction)/57.2958) and headwind = wind speed * cos((runway heading - wind 
direction)/57.2958). 
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Deployment notes: 

November 11, 1999: 

Residence time validation method -> A case study today of note. The wind line wake file at 
991 1 1 1_200914 produced an exceedance time of 75 seconds. Examination of conditions revealed: 

1. The 20:00 GMT AW AS crosswind was very light, less than 1 m/s. 

2. The wind line file was for a B757 at the wind line window (X = 982 meters). The lateral 
residence times were 44 sec and 88 sec for Port/Starboard wakes. The vertical residence 
times were given as 9999, which is normal for the wind line. 

3. The Pred_Tau file for 2000Z for the B757 at X = 982 gave a lateral residence time of 9999 for 
both wakes and a vertical residence time of 13 sec. 

4. Therefore the wind line file agreed with predictions in the lateral (in that the observed lateral 
residence was long and less than predicted) and the wind line file did not contain data to 
refute the vertical prediction (wind line does not do vertical. Yet the process produced a 75 
second exceedance.) 

5. This case may explain the exceedance seen in 1998 analysis and strengthens need to 
revisit comparison process, use of 9999 both for no data and long tracks, etc. 


11/18/99: 

Another residence time case study: Pulsed Lidar at 991 1 18_1438. Exceedance = 29 sec 

1. Winds are strong and from the south. 

2. The wake file is for a B757 at X = 1702 meters (initial altitude about 106 m. 

3. Wake file gave times (starboard wake is critical, see wake file Interface Control Document 

(ICD) for format). 

9999 9999 9999 9999 9999 9999 9999 41 

44 60 

4. Pred_Tau file for B757 at 1430 gives times 

9999 15 15 50 49 9999 15 15 50 49 

Therefore the prediction was for a 15 sec time based on sink while the wake file did not validate sink 
and provided a 44 second time based on demise. 

Four conclusions/questions: 

1. Need more intelligent compare logic and separate compare for each wake factor. 

2. Not all exceeds are hazardous. 15 Vs 40 seconds may not be an issue since aircraft 
cannot be separated by as little as 40 seconds. Likewise errors when the prediction is 
greater than about 90 seconds may not be an issue. 

3. May need different logic for "scientific" or demo evaluation of the system than for an 
operational safety system. 

2/9/00: 

1. Need to refine system buffers (N_Sigma, nowcast \s. observed, sink rate, constant bias, dual 
safety corridor (inner for validation and outer for spacing) optimization. 

2. Design of alerting method, timing if a wake lasts longer than expected and aircraft must be 
waved off - Vs system that tracks multiple wakes and opens up early based on trends. 

3. Need for much better logic to compare predictions and sensor observations of the wake. Stop 
using 9999 for both long life and invalid data (loss of information), scientific Vs safety validation. 


3/20/00: Noticed throughput values jumping or oscillating by about 2 aircraft per hour at times, for 
example from 1330 to 14 to 1430 Z on 11/12/99 the throughputs went from about 32 to 30 to 32. 
Since the default TP also made this swing, the evidence pointed to headwind. An analysis was 
done on 3/20 and I sent the summary to Bo Trieu & others. 
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My notes were: 

Evaluate Throughput (TP) dip at 1400 on 11/12 

Baseline > Run with weather files from 1330, 1400, 1430 Z => get TP dip from about 32 to 30 

1 . Substitute 1430 TDATA file for 1400, both flags & data => get dip 

2. restore TDATA and do substitution for EDATA => still get dip 

3. restore EDATA and do substitution for atmpro => removed dip 

4. restore files and use 1430 QA flags in 1400 atmpro => get dip 

5. restore all and use 1430 wind data in 1400 file => removed dip 

therefore issue is in ATMPRO winds 

6. restore all files and take absolute value of headwind to remove some 
tailwind at 1400 => still get dip 

7. restore all and use 1430 headwind values in 1400 file up to 950 meters 
=> removed dip! 

8. baseline except headwind = 0 in 1400 file => still get dip 
Could there be an error is use of headwind internally? 

9. Try baseline files except that headwind at 600m at 1400 is taken from 1430 file. 

=> dip in TP was reduced, dip in DTP was gone! 

Re-verified with two fresh runs - changing a single headwind value at 
600 meters (Z of spacing point) removed the dip! Why? 


10. Try ramping through HW @ 600 meters to get TP at each value: 


Base 


from 1430 


HW@600 

TP 

DTP 

-0.42 

30.113930.0244 


0 

30.113930.0244 


0.50 

30.113930.0244 


1.00 

30.1139 

30.0244 

1.50 

32.08 

31.9784 

2.00 

32.08 

31.9784 

2.50 

32.08 

31.9784 

3.00 

32.08 

31.9784 

3.50 

32.08 

31.9784 

3.96 

32.204 

32.1017 

4.00 

32.204 

32.1017 

5.00 

32.6123 

32.4031 


The email to Bo, Don, Jim was: 

Update on the throughput value step changes: 

I ran most of this morning to isolate the causes of the rapid changes in throughput observed on the 
plots we discussed. It was fairly quickly isolated to the head wind column of the ATMPRO files. 
There was nothing obviously wrong with the files on hand, so I looked into the equations for use of 
the headwind data. The headwind at two altitudes is used to estimate the average headwind 
between the "spacing point" and each window when computing "approach” spacing time intervals 
from "window" intervals. One altitude is the glide slope at the window and the other is the glide 
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slope at the spacing point. As currently configured the spacing point is at 11128 meters from 
runway and the altitude there is 600 meters. 

The sudden drop in throughput for the time being examined (14Z on 11/12) could be eliminated by 
editing only one value in the ATMPRO file, and that value was the headwind at 600 meters. At 
13:30 it was 3.77 m/s, at 14Z it was -0.42 m/s, and at 14:30 it was 3.96 m/s. When the 14Z data 
was edited to change the 600 meter headwind from -0.42 to 3.96, the throughput drop at that time 
vanished. 

A quick look at the sensitivity of the equations suggests that a 4 m/s headwind change or a 1/2 
nautical mile change in window spacing can alter throughput by more than 1 aircraft per hour. 
Another factor contributing to the jumps is the use of rounding of the spacing values prior to 
computing throughput. The approach spacing values are not used as is, but are rounded to the 
nearest 1/2 mile before calling the throughput equations. I did not intend for this rounding to be 
applied to the default spacing values but apparently it is. The following table shows the throughput 
and default throughput from AVOSS as the headwind at 600 meters was changed: 

HW@600 TP DTP 

Base -0.42 30.113930.0244 

0 30.113930.0244 

0.50 30.113930.0244 

1.00 30.113930.0244 


1.50 

32.08 

31 .9784 

2.00 

32.08 

31 .9784 

2.50 

32.08 

31 .9784 

3.00 

32.08 

31 .9784 

3.50 

32.08 

31 .9784 

from 1430 3.96 

32.204 

32.1017 

4.00 

32.204 

32.1017 

5.00 

32.6123 

32.4031 


There are discrete jumps in throughput rather than a smooth change. 

Bottom line??? 

1 . The throughput jumps are explainable from the weather files and the throughput equations. 

2. The system is very sensitive, as-is, to the noise in the wind estimates at altitude. 

3. The throughput estimates may or may not improve (smooth out) as the radar profiler and 
south sodar are repaired, hopefully improving the wind estimates. 

4. Throughput can change by 2 aircraft per hour for a 1/2 mile spacing change. 

3/22/00: 

Investigate effects of setting the rounding interval to 0. 

Run 11/12 at 1330, 1400, 1430 with round = 0 and 0.5 

round = 0 round = 0.5 



TP 

DTP 

TP 

DTP 

1330 

32.535 

31.690 

33.003 

32.102 

1400 

30.824 

30.761 

30.114 

30.024 

1430 

32.450 

31.653 

33.003 

32.102 


Effects were: (1 ) delta throughput (TP) at 1400 was about 1 .7 Vs 1 .9 and 

delta default throughput (DTP) was 0.9 Vs 2.1 when rounding was removed. (2) peak TP 

was less than with rounding. 
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Repeat test above with sweep of HW at 600 meters with round = 0: 


HW@600 

TP 

DTP 

e -0.42 

30.8241 30.7608 


0 

30.919 

30.8492 

0.50 

31.032730.9552 


1.00 

31.147431.062 


1.50 

31.263 

31.1696 

2.00 

31.379531.2781 


2.50 

31.497 

31.3874 

3.00 

31.6155 

31.4975 

3.50 

31.7349 

31.6086 

30 3.96 

31.845731.7115 


4.00 

31.8554 

31.7205 

5.00 

32.099431.947 



Therefore the rounding is having a significant effect on throughput (TP) and default TP. A plot of TP 
and DTP Vs time for all of 11/12 was made for rounding = 0 and 1/2 nm, the zero value provided 
much smoother TP variations with time. 


3/24/00: Discussions were held with regard to biasing the nowcast weather products with local 
observed weather prior to calculating future throughput. Presently small (about 1 m/s biases in the 
low-altitude nowcast winds are having large effects on projected runway acceptance rate. Analysis 
indicates that local observations could improve performance by removing the biases and using the 
temporal trends provided by the nowcast to estimate future arrival capacity. This process could not 
be implemented and tested in time for the final system demonstration so the discussion has been 
removed from these notes. 


3/29/00: 

Have verified Compare outputs with wind line files, Lidar_L files, and Lidar_N files. All operate 
correctly, singly and in multiples. Found numeric errors in calculation of standard deviation and 
submitted software correction to CSC. The issue has only appeared when calling compare multiple 
times with the same file set. CSC is modifying code now and says that even if the output for one 
compare is in error, the intermediate storage is not affected and will be correct with the next call. 

Have run the entire 1999 deployment in batch mode with the new Compare code. Results were 
excellent, with no hard exceedances noted and very few soft exceeds. We are hand examining 
specific cases for verification, to date a lidar file and two wind line files that produced large exceeds 
in the first code and a positive buffer with the new code. All so far have been correct. Several "got- 
ya's" noted: 

1. Remember that the wind line compare now is only of the lateral drift, that is, the predicted Tau 
is taken from the lateral motion only. That is the reason that two large exceeds on 1 1/19/99 
turned into positive buffers, since the predicted sink time was not used in the score. 

2. The alternate demise definitions are used for the lidars, and the alternate drift is used for the 
pulsed lidar. See wake file ICD. 

3. The SW_requests are ambiguous as to which demise values in the Pred_Tau file to use in 
comparing predicted Vs observed decay time. The documents say DL and DR, but email follow 
up changed that to DVL and DVR. 
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Plan: Compile and run batch mode with original compare code and compare both batch runs to the 
real-time log files to determine if the batch process is altering results. 

Results: Only ran 12/01/99 due to need to edit Pred_Tau files to remove new data in VI .3. Found 
that new runs had more wake files to work with than were captured in the real-time statistics files. 
More buffers were computed on the batch rerun than in real-time, otherwise the trends were the 
same. Numerous cases that had created large exceedances in VI. 2 Compare now produce 
smaller soft exceeds or even positive buffers with VI. 3, see "got-ya" 1 above. 

One case: NASA lidar on 12/01 at 172320 gave a 105 sec exceed initially and now a 60 sec soft 
exceed. The initial 105 sec exceed is due to 17 sec predicted vertical Vs 122 sec observed decay 
of starboard wake (77 for port). This file is likely in error on the right wake (sank to 19 meters at 47 
sec life then rose to 1 14 over the next 60 sec with little decay). This is not realistic and likely due 
to tracking the next aircraft. New Compare gave soft exceed due to "9999" time for right sink time. 
The value of 105 changed to 60 due to the TauMin and TauMax limits of 60 and 120 sec (TauPred = 
17 adjusted to 60 and TauObserved = 122 adjusted to 120). ]F the wake file were valid in its wake 
rise data, this would have been a legitimate hard exceedance. The limitation here in determining 
soft Vs hard is the use of 9999 for no data, bad data, and legitimate wake-in-corridor data. Future 
implementations must address the issue. Simply reporting the last time in the file as the residence 
time is not satisfactory, since the file could end at 60 sec then claim a 60 sec residence (unsafe). 

A method of handling "wake was still there at last observation" is needed. 

Another case was pointed out to lidar group as an error (tracked next aircraft at end of track to give 
erroneous rising wake). This case was MD-80 on 12/03 at 150629. VI .2 gave a 57 sec exceed and 
VI .3 gave a 14 sec soft exceed.. The value changed due to the TauMin limit (17 sec vertical time 
changed to 60) and it was soft due to 9999 vertical time. 

Possible solution: Sensor reports the file end time of the wake factor is still in the corridor at that 
time, perhaps with a flag to indicate that the wake was still there at track loss. AVOSS then 
compares to prediction. If the factor and file and time are the same and less than predicted time, 
then no validation is possible. If the factor and file time are the same and greater than predicted 
then a hard exceedance can be reported. This differs from the current code only in that a positive 
buffer cannot be calculated if the end-of-track time become the factor time. Example, if the wake 
track lasts 90 seconds and the wake is still in the corridor at that time, currently the sensor reports 
9999 residence. In the proposed logic the reported time is 90 seconds but AVOSS cannot report a 
positive buffer, only an exceedance from it. 

3/29/00: 

About 1 week ago - ran batch runs with AVOSS V2.4 to determine throughput performance with 
various sink rate factors. Ran for SINK_PERCENT = 0, 50, 100%. Results are tabulated in 
"Three_Sinks.xls" sheet. General results: 

Reducing effective sink rate from 100% to 50% produced small decreases in throughput. On most 
days the throughput decreases by less than 1% (i.e. from a 6% throughput increase with SINK = 
100% to 5% throughput increase with SINK = 50%). The largest decrease was on 11/30 when 
throughput decreased from 1 1 .1 % to 9.2%. The average loss of TP increase was 0.6%. When 
disabling sink altogether the loss was much greater, averaging a loss of 2.5% with a max loss on 
11/30 of 5.4%. This suggests a good opportunity to increase safety margins and reduces 
exceedance counts with small throughput losses. The optimal range of SINK_PERCENT is TBD 
but likely between 40% and 80%, and would likely be weather dependent. Actual aircraft spacing 
reduction in test bed use should start with SINK_PERCENT = 0 until the wake stalking factors can 
be better predicted. 
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4/3/00: 

From batch runs to study effects on changing N_Sigma and percent of sink applied and the 
rounding interval: 

This folder contains sensitivity runs, including all Dist and 
Pred Tau files. 


General parameter interests: 

- Rounding 0,0.5 nm 

- % Sink 0,50,75,100 

- N_Sigma 1,2,3 

- TimeAdd 0,5,10 

- Demise Def (studied by Riddick) 

- A/C selection (default only at this time) 

- Corridor Option (only #2 at this time) 

- Disable Lateral (not at this time) 

- QA_Enable (enabled at this time) 


Eventually compare to wake files for exceed values: 

- Number of Hard exceeds (=0?) 

- Number of soft exceeds 

- Maximum or mean exceeds 


Initial Runs begun 3/30/00 with AVOSS V2.4: 


(TimeAdd = 0) 



Run # 

Round 

%Sink 

N_Sigma 

1 

0.5 

100 

1 

2 

0.5 

50 

1 

3 

0 

100 

1 

4 

0 

50 

1 

5 

0.5 

100 

3 

6 

0.5 

50 

3 

7 

0 

100 

3 

8 

0 

50 

3 


Write one log file per day. Zip file names are SensRun## 
where ## is run number. 


Results of 1st eight runs: 

Plotting average throughput increase by day showed 4 groupings. 

Runs 1 & 3 almost overlapped and had the highest throughput 
increase (100% sink, N = 1, rounding 0 and 0.5) 

Runs 2 and 4 were the next best and not far below the first group. 

They were 50% sink and N = 1, both roundings. 

Runs 5 and 7 were next, and beginning to be seriously degraded from 
the baseline. They were 100% sink, N = 3, both rounding. 

The worst was 6 and 8, with 50% sink, N = 3, both roundings. 

Conclusions: 

1 . The rounding interval makes no significant change in daily throughput increase (but other data 
shows it may have a significant effect on changes between updates). 
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2. Changing the wind standard deviation multiplier from 1 to 3 has a larger effect on the 
performance than changing the sink rate from 100% to 50%. 

3. Values of sink between 50% and 100% should have acceptable impacts on performance as well 
as N = 1 or 2. Combining high N and low sink provides significant performance reduction. 


4/4/00: Al Zak had an interesting observation about the list of exceedances I provided. The time of 
most were in the 23Z to 01 Z evening transition period. This is significant, as they were wind line 
exceedances and therefore due to lateral drift errors. A common thread was low cross wind, about 
1 .5 m/s, and very low cross wind standard deviation values, about 0.02 to 0.1 1 m/s. The cross wind 
standard deviation is taken at the tower 40 meter level and extracted upwards. This is valid in well- 
mixed PBL but is not when an inversion forms above the tower. A future system will need to 
consider this and either open up spacing during this period, provide other sensors such as lidar to 
measure standard deviation profiles, or develop algorithms to estimate worst-case standard 
deviation above the inversion, perhaps based on models, forecasts, or the standard deviation that 
existed before the inversion formed . 


5/13/00: 

Have examined about 3 of the time periods for which AW AS wind standard deviation was low, and 
we saw a wind line drift exceedance. When the minimum and maximum cross wind is compared to 
the (mean+- standard deviation), the min/max gave a slightly larger confidence interval, by a few 
tenths of a m/s. Later Bo asked if we were really using variance or standard deviation. Standard 
deviation would also have provided a slightly larger interval. 

The issue of finding the best metric for cross wind uncertainty requires further study. The current 
method appears to work well, but leads to drift exceedance in a very few cases. Study of this issue 
would be enhanced by modifying the software to allow real number multipliers to standard deviation. 
We are currently limited to the integers 0, 1 , 2, 3. 


5/22/00: 

Realization that the current method of flagging convective storms and gust fronts is only a half-hour 
product. Operationally AVOSS needs another process running at higher than every half-hour for 
issues such as this and for feedback to ATC from safety monitoring. 


6 / 1 / 00 : 

Several system timing issues have been noted: 

1 . The QA flag that advises that a gust front or convective storm is effecting the approach is set 
based on the presence of an event within the 30 minutes preceding the AWAS profile 
calculation. This means that a storm on the approach will not cause default spacing while the 
storm is there, but will cause default spacing in the next half-hour period. A test bed system 
needs predictions of such meteorological events and the ability to tell ATC about require 
spacing changes in between the regular half-hour updates. 

2. Someone suggested that we could run multiple copies of AVOSS, all at 30-minute periods, in 
order to provide smoother spacing changes or predictions that spacing will change at the next 
update. If weather trending is added to persistence this could provide benefits in deriving that 
derivative. 

3. There is a several minute time lag between the file time of wake files (they are referenced to 
aircraft passage time) and the time at which the wake file is received by AVOSS. The current 
"compare" logic runs on half-hour periods, and throws out the old Pred_Tau file when a new one 
is created. The result is that wake files started one to two minutes before the half-hour may not 
be received until after the half hour. The current scheme will not use those files in the scoring 
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process. We appear to be losing about 2 to 3 wind line files per hour from the scoring process. 
Currently AVOSS runs at 1 and 31 minutes past the hour. 

4. No process is in place to actually feedback wake prediction errors to the spacing values. That 
is a feature to be added in the next project using the data gathered from this project. 


6 / 12 / 00 : 

Recent bug finds and fixes: 

1 . Examination of May runs showed numerous "spikes" in spacing values Vs time. Examination 
showed that on some days 1/3 to 1/2 of the ATMPRO files were failing the quality check. Further 
examination shows that the failures were due to degraded individual sensor performance, ie., 
combination of profiler and sodar, and that the QA criteria appeared too strict. It was possible for 
the overall QA to fail with valid weather being provided, in situations where a sensor was degrading 
but other, redundant data was available. Al Zak examined the data and suggested that the Lincoln 
AWAS assessment of the wind profile quality (flags 1 through 4) was adequate. The QA criteria 
has been modified to avoid use of the individual sensor QA flags and rely on the Lincoln process 
flags, as well as the gust front flag. 

2. Review disclosed that the ATMPRO file from AWAS was providing cross wind variance, while the 
TAPPS was providing standard deviation. The correct units are standard deviation. To avoid 
splitting the years of data into two formats, the AWAS file is left as-is and the AVOSS software has 
been modified to take the square root of variance when an AWAS file is read. This change alone 
prevents 6 of the 34 wind line exceedances (17%) in the 1999 deployment data set. 

The two changes above are incorporated into AVOSS V2.5, which began real-time operations at 
13:30 Z on 6/12/00. 


7/6/00: 

Batch runs of 1999 deployment data with V2.5 show: 

1 . Vastly more wake compares - fixes timing issues and revised QA results in far more good 
weather QA cases for wake compares. Now have 952 compares \s. just over 400 in real- 
time in 1999. 

2. Of 952 comparisons we have 656 class 1 (taumin = 50), 244 positive (2 hard), and 52 
negative. 


3. Mean throughput increase from entire deploy fell to about 5%. Did quick study of exceeds 
vs. throughput for N_Sigma = 0 and 1, and crosswind lockout threshold = 1.0 and 1 .5 m/s. 
Found: 


N_Sigma 

Cross wind 
lock 

Average 

throughput 

increase 

exceeds 

Wind line drift 
exceeds 

0 

1.0 

7.46 

82 

59 

1 

1.0 

4.94 

52 

29 

1 

1.5 

4.10 

46 

23 


4. Suggests need for parametric tradeoff of exceeds and performance, and methods of 
quantifying wind confidence intervals. Keep in mind that a drift exceedance is not 
necessarily a safety error (sink & decay at windline not scored) and that a genuine drift 
exceed may not be a safety issue depending on location of the wake at the time. Also 
consider wind confidence vs. stability class, time of day or year, etc. rather than use of 
constant gains in all weather. 
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Table to collect software enhancement ideas: 


Change 

Reason 



Remove hard-coded description of the corridor 
and place it in a parameter file. Do not 
"increase" corridor width at glide slope intercept 
altitude, but use a policy flag 

Ease of performing tradeoff studies, 
evaluating improved flight technical error, 
parallel runway concepts 

End-to-end functional decomposition of the 
software and rewrite from ground up 

Improve modularity, implement other ideas 

"Disable" flags due to parameter file settings 
and QA tests are scattered through code. 
Gather these into 1 or at most 2 modules to 
implement QA and policy restrictions on 
spacing 

Improve understanding of code, reduce 
chances for implementation or interpretation 
errors. 

Implement feature to determine which windows 
are critical to the spacing values, or which ones 
could be dropped from consideration (i.e. by 
showing the spacing would not increase for any 
aircraft pair by any significant amount if a 
window were removed. 

Tremendous costs benefits to the system if 
windows far from airport can be ignored. 

Make weather QA a function of altitude and 
make ability to disable lateral, vertical, or 
demise a function of altitude 

See note of 6/15/99. May improve 
performance or cost in situations where one 
weather parameter is good at low altitude but 
questionable at high altitude, while another 
weather parameter is good at altitude and is 
removing the wake 

Integrate the currently-separate "scientific" and 
"real-time" data sets, in strictly controlled 
modular sets (raw sensor, processes 
consensus files, etc). Provide common data 
processing and visualization tools 

Allow for faster assessment of alternate 
mans of processing sensor data (i.e., wind 
min/max intervals Vs standard deviation- 
based intervals) and quick answers to what-if 
questions (EDR as function of wind?) Must 
provide controlled access to copy of real-time 
process by researchers. 

Add the ability to run an arbitrarily oriented 
runway. Some code is hard-wired for runway 17 
at DFW. 

Obvious 

Add outputs for parallel runway operations 
(alternate corridor size, product formats). 

Obvious 
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Figure 1 - General System Architecture. The core code provides one set of wake 
predictions and spacing calculations for each call with weather, aircraft, and parameter 
data. EDATA, TDATA, and ATMPRO are file name prefixes for turbulence, 
temperature, and wind profiles, respectively. DefSpace is a file providing minimum 
threshold spacing for runway occupancy time considerations as well as the FAA spacing 
criteria. AVOSS was run with both observed weather (top inputs) and nowcast 
(predicted) weather (bottom input) but aircraft spacing values and wake comparisons are 
only provided for observed weather. 
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Each TAR file contains: 

- Atinpro 

- Tdata 

- Edata 

for 30 minute blocks for 12 to 18 hours 


Note: 

EDR - Eddy Dissipation Rate 
IDL - Interactive Development Language 
QA - Quality Assurance 
RASS - Radio Acoustic Sounding System 
TAPPS - Terminal Area Planetary boundary layer Prediction System 
Wx - Weather 


Figure 2 - Data flow within the AVOSS weather system. Wind profiles and eddy 
dissipation rate (EDR) is provided by MIT Lincoln Laboratory systems based on field 
sensor data. Derivation of thermal profiles and EDR profiles are provided within the 
AVOSS shell code. Nowcast weather products are provided in identical format to 
observed weather, and the field sensor QA processes are not applied. 
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Top-of-approach, or “Spacing Point” 



Runway Threshold Intercept Altitude 


Figure 3 - Runway axis system and approach corridor. 


Weather data 
Parameter file 
AC database 



Notes: 

•“Residence time data” provides lateral, vertical, and demise residence time values for port 
and starboard wake for each aircraft at each approach window loc ation. 

•Each data type (wake tracks, residence time data, spacing matrix, and runway throughput) is 
written to disk file for archival and comparison with sensor dala as appropriate. 


Figure 4 - Flow of data from weather and aircraft parameters to wake residence time and 
approach spacing. 
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Figure 6a - Comparison process for scoring predicted wake 
residence time with observed residence time 
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Figure 6b - Comparison process continued 
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Yes 



APA refers to the wake predictor algorithm. 

HL, VL, DL are horizontal, vertical, and demise residence times of the left wake, 
HR, VR, DR are the same times for the right wake 

ResTimeP and ResTimeS are observed residence times of the port and starboard 
wake due to cdl factors. 


Figure 6c - Calculation of predicted and observed residence time an buffer 
calculation, including special rules for the windline data and times that span 

TauMin or TauMax 
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Hard comparisons between predicted and observed residence time is only possible when the factor 
(drift, sink, demise) that establishes the predicted residence time has been quantified by the sensor. 
The factors that determined the predicted residence will be determined and then the wake file will 
be examined to determine if those factors have “9999” values for the critical wake. When the 
sensor returns “9999” for a time there is no certainty that the wake remained in the corridor, or even 
that the wake was even tracked and the buffer is soft. An actual situation from a lidar file was: 

Source Drift time Sink Time Demise Time Predor Obs Tail 

Predictor 9999 17 72 17 

Sensor 9999 11 Port 77 Port 122 

9999 Starboard 122 Starboard 

In this case the software version 2.3 computed a 122 - 17 = 105 sec exceedance. This exceedance 
is soft because we do not know if the sink of the starboard wake actually took place in less than or 
more than 17 seconds due to the 9999 value. This case is used as an example ( italics ) in the 
flowchart below. The word “factor” refers to drift, vertical, or demise time. 



Example above, Buffer is soft 


Figure 6d- Criteria for Soft and Flard Residence Time Comparison with 

example 
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Figure 7 - Calculation of encounter probability from distributions of following 
aircraft position and wake positions at various elapsed times from generating 
aircraft passage. 
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